[ http://mc4j.org/jira/browse/STS-441?page=comments#action_10998 ] Tim Fennell commented on STS-441: ---------------------------------
I'm not actually sure what to say to this. From the current javadoc at http://stripes.sourceforge.net/docs/1.4.3/javadoc/ : protected String[] getFormatString() Returns an array of format strings that will be used, in order, to try and parse the date. This method can be overridden to make DateTypeConverter use a different set of format Strings. Two caveats apply: Given that pre-processing converts most common separator characters into spaces, patterns should be expressed with spaces as separators, not slashes, hyphens etc. In all cases getDateFormats() will return formats based on this list preceeded by the standard SHORT, MEDIUM and LONG formats for the input locale. I understand that you may disagree with what's being done, but the documentation of the exact method you are overriding is quite specific on this point. We are making some changes for 1.5 and I'll ensure that there's also class level javadoc describing this. > Custom DateTypeConverter classes mysteriously fail > -------------------------------------------------- > > Key: STS-441 > URL: http://mc4j.org/jira/browse/STS-441 > Project: Stripes > Issue Type: Bug > Components: Validation > Affects Versions: Release 1.4.3 > Environment: Solaris 11 > Reporter: Alan Burlison > Assigned To: Tim Fennell > > I was trying to get Stripes to accept dd/MM/YYYY format dates, so I extended > DateTypeConverter as follows: > protected String[] getFormatStrings() { > String[] o = super.getFormatStrings(); > String[] n = new String[o.length + 1]; > n[0] = "dd/MM/yyyy"; > System.arraycopy(o, 0, n, 1, o.length); > return n; > } > And in my Action class I had: > @Validate(converter=my.project.MyDateTypeConverter.class) > private Date startDate; > And it didn't work - it rejected perfectly valid dates such as "31/12/2007". > The reason is that DateFormat replaces characters such as "/" in the input > string with spaces, but it *doesn't* do the same to the format strings, so > it ends up trying to match "31 12 2007" against "dd/MM/yyyy", which fails. > I'm not sure if this is a documentation bug (i.e. the docs should point out > that custom format strings shouldn't include non-space characters), or a code > bug (i.e. format strings should be subject to the same replacements as the > input string), but it surely *is* a bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://mc4j.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Stripes-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-development
