Input field validation - not required numeric field

[Former Member]

I have an input field among other fields on the form.

This field should be numeric only (0 - 99) but it is not required field and can be left empty.

I can not use integer/short built-in types - empty values are not allowed there.

I tried to use decimal type instead (it uses bigdecimal java class, null is allowed).

I can not figure out how to set format to not allow decimals and letters. I have set a format to "#0". When I input

AA in the field, I get an error message Enter the value in the format -2733

Any suggestions are welcome.

Julia

[Former Member · Accepted solution]

Hi.

I usually create an additional calculated attribute of type string, then do any validations in the setter method before setting the new value to the real underlying context attribute.

/Mikael

[Former Member]

Mikael,

Ideally it should work like that:

User enters bunch of error on the screen.

Data type errors are checked first by the framework and they reported to the user - user corrects the errors. Then coded validation

(business logic type: cross fields or required fields) kicks in - errors reported to the user.

I will follow your advise and use calculated string for all the fields except dates. For dates I will have to use a date (even as a calculated field).

In our case it will work like that:

User enters bunch of error on the screen, one of them is a date error. The framework will report a date error first - user corrects it. Then the coded validations (including data type and business logic type) report errors.

We will have to live with it.

Thanks a lot for your answers.

Julia

[Former Member]

Mikael,

What about date field?

Do you use the framework defined date field or you convert the date into string as well?

The date field has a very nice calendar shows up next to the field w/out any coding on my part.

Julia

[Former Member]

Yes. Datefields are nice. All fields that isn't bounded to strings are converted by the framework. The framework will do the data conversion for you before you get any control.

You can still have the calculated attribute typed as a datefield and do more intelligent validations.

For instance check that the to-date is after the from-date etc...

Earlier there was a bug in the date control, and you couldn't enter characters or anything except a correct date, or the application would give a runtime exception.

This has been fixed, and the user will get a standard error saying this is not a correct date...

Isolating validation of fields in the setter method of a calculated attribute is still very convinient.

• It's easy to read your code and find your validations.

• Your validations are reusable. You don't have to re-write any validation on each action in your view.

• You have the possibility to use more user-friendly error messages.

[Former Member]

Mikael,

Does that mean that you check yourself min/max values and create an error message for each error?

Also there are more fields on the form and we need to support more than one language.

I thought that if we use built-in types or Simple Types from the dictionary, the framework provides the validation; this validation takes place before any other methods/events in the code.

If some data type validations are coded and some are framework provided, the framework validation messages are shown whenever there are errors in the fields. The coded validations will not be even executed in that case.

If user fills the form and makes 2 data type errors, one is framework validated and the other one is code validated, he will not get 2 error messages at once.

Julia

[Former Member]

Hi.

Yes, I think you should use getters/setters. Even if the framework would take care of datavalidation, the error messages wouldn't be very pretty.

You can have much more control over the messages you show the user in a setter method.

The user would get all the error messages you would produce in a request-responce cykle.

If you want labels supporting different langugages, you can either have the label values in xlf-files (standard for all view-hardcoded texts), or you can create your own type with labels in the dictionary and translate them there.

Use the Message Pool to support error messages in different languages. The message manager supports arguments inside the message text. I.e. " is not a valid value for field ", to create dynamic messages. (This is no magic. It's build into Java, and can be even more complex)

I can't see any disadvantages by using calculated attributes. If you bound the fields to an attribute not of type string, the conversion would be done before any of your code is called. Meaning you would have no control over the behaviour in that way.

Calculated fields are perfect for doing validations. I've come across a validation that said IF something is entered in fieldA, then fieldB is mandatory, otherwise it isn't...

That type of validation can't be done by the framework at all...

/Mikael