GeorgeJeffcock wrote:
Hi Charles,
To add to Crispin response, I was asked this other day and this is what we came up with:
Knowing you use 5250 some of the UI may or may not be relevant..
Create a numeric field
4 long, 2 dec places (you may want it to be character to allow UI to be Blank instead of 0 for empty)
Add ALL the values possible..ie 0.25, 0.50, 0.75 for the literals and maybe 1/4 hour, half hour, 3/4 hour as the value object names if so required for user understanding)
Add State to field called Allowed Values
Add Allowed Values State May BE SYS Any (to help in validation function)
That's an interesting idea...hadn't considered adding all the allowed values...
GeorgeJeffcock wrote:
Add Empty Value, Default Value, High Value, Low value triples to the field (to help in UI initialisation and validation function)
Add Label to field to be used for the UI left label and error message
Control Sys Combo or Text (if you are able to use spin controls)
Honestly I'm going to have to look at what Empty/Default/High/Low would mean...I can't think of any of our fields that use them. :smile
Given that we're 5250, the Control doesn't matter...5250 doesn't support spin controls.
GeorgeJeffcock wrote:
Add a scoping validation function (or unscoped to be called by all four of your fields)
Function (scoped or unscoped has this pattern field as input)
Output field of *Message text to be used by Go sub Send Message if field was in error
Output field FailedValidationYesNo or equivalent as these validation functions in general you find as they get complicated the calling function needs to know when the validation function has run successfully but the data failed validation as opposed to the validation function having a error handling error.
Within the validation function you know can put your bullet proof code in ie, don't rely on the UI to do the validation, these validation functions can be called from anywhere in the future..ie validation xml response..
The AllowedValues state will prove useful here as opposed to creating a long OR condition. Be helpful to the user here as you will only need to write this once in this function so you should alert the user to high low values, increments amounts etc, not just "Value entered not Valid"
Valid the increments by dividing the input by .25 and you must get a result with no decimal places..think we used REMAINDER to check
UI see Spin Control Property if you are using java, winc client. Where you can set up most of your validation rules as Input restrictions for the field.
Combo box could be used but we went for spin. The point being the UI can help the user enter the right data but the validation functions must assume the user has entered utter rubbish ie entered "-0A.04"
I like the idea of an unscoped function. Along with the messge and validation handling ideas...wish all our fields had stuff like that.
Interesting enough, with 5250 if I describe the field with a set of allowed values...the UI does in fact enforce those values...unlike WinC or Java...which means there's little reason for a separate validation function at this point in time.
GeorgeJeffcock wrote:
Depending on your company patterns the validation functions can be called by meta or explicitly, and remember when testing the validation function return you need to first Check Call Status, then Returned Status then finally ValidationFlag. Some sites have added a FailedValidation to Returned Status which is useful!
Some thoughts on your specific scenario is that the fields are related. One affects the other, cant surely have 24 hours labour as well as travel etc, so I would also look a further level of abstraction on having the pair of fields as input to the validation functions so that you can validate the values together...
Most places, the validation should be called by Meta....though it's possible I'd have to call it explicitly somewhere (Our OBASE patterns leave something to be desired)
I like you idea of validating the fields as a group, actually when all 4 are added together it should be <= 24 hours.
But how would I do so? my understanding is that FLD validated by FNC can only do basic validation that doesn't require referencing other fields...
I supposes VW validated by FNC might be a solution....or perhaps I could define the field as a structured or array field...
What were you thinking when you said "further level of abstraction"?
Thanks!
Charles