Hi Richard, > BUT as I started to write the TypeConverter I missed the formatType property. > In order to support date, dateTime and time, I will have to somehow > detect the format the user used to enter the date. It would be very > easy and more consistent if TypeConverters would support the the > formatTpe too - at least in my mind... Is there a reason that I don't > see, why this is a bad idea?
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. 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. 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
