|
Joost Schouten made changes - 22/Dec/06 09:14 PM
Craig McClanahan made changes - 27/Dec/06 10:38 PM
I agree with you that just one message is the quickest solution, however, you and I know what integers, floats etc. mean. Most of my application users do not. I want to present them with a message they understand. Also, currently when two validators are in place (eg. requires and email), they also have an order which might result in two messages after each other ("requred" and on second submit "wrong format").
Maybe it would be best to create an new validator type for number. So that if you want you can add the number validator in front of your integer validator. What do you think?
I currently solved my number chacking problem as follows:
<h:inputText id="myInteger" value="#{contact.myInteger}"> <s:commonsValidator type="float" message="{0} should be a number" arg="#{labels['labels.user.myInteger']}" server="true" client="true"/> <!-- would like to use a double, but that fails. posted a message on the shale user mailinglist--> <s:commonsValidator type="integer" arg="#{labels['labels.user.myInteger']}" server="true" client="true"/> </h:inputText> <h:message for="myInteger" styleClass="error"/> This results in a message telling my users to use a number, if they entered text or a wrong format. Once that is correct, and it is a float in stead of an integer, they'll get told to us an integer in stead. Obviously I would propose to add a numbet validator type to the s:commonsValidator and a numberValidator to the commons package. Do more people support this? If so I can build the validators and submit them.
Rahul Akolkar made changes - 23/Jan/07 04:40 PM
Jeff Turner made changes - 09/Aug/07 07:15 AM
Antonio Petrelli made changes - 08/Jan/09 08:56 AM
Antonio Petrelli made changes - 08/Jan/09 09:08 AM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Regarding quotes, I think they do indeed need to be escaped ... the default processing seems to remove them, and other translations for these messages do not seem to use them. Regarding preprocessing, that would be an interesting idea. But, if I type "abc" into a field that expects an integer, and get back "{0} is not a number", that does not give me enough information, right? I can type "123.456" and get yet another error ("{0} is not an integer"), and I'll start grumbling "why didn't you tell me that in the first place?"