Hi Freddy,
> The DateTypeConverter already supports several date formats, and it
> is easy to customize them to your own. The type converter is able to
> accept the user input in any of those formats.
Yes, but it is too lenient with dates. If the user makes a typing
error the date created is a total mess. Here's an example:
__________________________________________
SimpleDateFormat dateFormat = (SimpleDateFormat)
DateFormat.getDateInstance(DateFormat.MEDIUM, Locale.GERMANY);
dateFormat.setLenient(false);
System.out.println(dateFormat.toPattern());
Date parse1 = dateFormat.parse("2.2.2");
System.out.println(parse1);
Date parse2 = dateFormat.parse("2.2.02");
System.out.println(parse2);
-----------------------------------------------------------------------
OUTPUT:
dd.MM.yyyy
Thu Feb 02 00:00:00 CET 2
Thu Feb 02 00:00:00 CET 2
__________________________________________
In this case the user want's to say second February, 2002 but ended up
in year 2 .> Generally speaking, though, I don't think it's a good idea to have > a formatType property in TypeConverter. The user enters some data, > and it's your job in the code to parse the input. I agree that the > user should be allowed to enter data in several different formats. > But it's not like you're going to tell the user to select the format > that he or she used, in a select box, and then enter the input in a > text box, so that your type converter is given the formatType as a > parameter. Instead, I think you should just be as strict or as > lenient as you want in the format and parse the input in the > TypeConverter code. > > In the book I show an example of a TypeConverter for a phone number > that accepts several different formats: > > NNN-NNN-NNNN > (NNN) NNN-NNNN > NNNNNNNNNN > NNN.NNN.NNNN > etc. > > and with a regular expression it's fairly easy to do. I have read your book - I admit not with a 100% coverage but maybe 90% :-) Let me argue with another example: <s:text name="stock.risk" formatType="percentage"> This renders to an html input tag with a % at the end of the number. Submitting this form without changing the value ends up in a ValidationError. This is not what I would expect if I don't know the frameworks details and what I mean by inconsistent - from a framework user point of view. If the format type would be defined in the validation annotation, the type converter would be able to look out the information without posting the formatType. Same with the pattern. If I want the user to read and type a certain number with 4 digits after the decimal point, I have to define the pattern in the jsp and something else(mask/expression) in the actionBean. For my CalendarTypeConverter this means, that I will show my user a time and let him enter a date and time or only a date if do not make use of the Validation annotations. If I use Validation annotations I repeat my self and some voice in my had tells me that this is not a good thing :-) Did you catch my thoughts(I'm not very good in converting things from my mind to written words in a foreign language :-) )? If so, are the reasonable or did I miss something? Thanks, Richard > > What do you think? > > Cheers, > Freddy > http://www.stripesbook.com > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Stripes-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/stripes-users > ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
