Re: Proposal for DateField validation patch

2012-08-21 Thread Chris Cureau
While we're working on the DateField component, would it be time to
consider adding one of the MIT licensed TimeField components as well?
 Perhaps as an option on top of DateField?

On Tue, Aug 21, 2012 at 7:05 PM, trsvax  wrote:

> After discovering DateField does not really validate dates and finding it
> very difficult to make it validate I came up with the following code that I
> think makes things much easier.
>
> There are really 2 problems.
>
> First if you pass DateField a string for the format you get a DateFormat
> with lenient set to true. This allows dates such as 00/01/2000 and
> 45/01/2000 because DateFormat will do it's best to turn any string into a
> Date object. This means typos may be converted to a valid date and the
> application cannot tell that happened.
>
> The second problem is parse(string) just parses until it finds a valid date
> and ignores trailing characters. Again this means typos slip thru for
> example 01/01/200- will be the year 200 and not an error.
>
> So I patched DateField with the following:
>
> @Parameter(defaultPrefix = BindingConstants.PROP,
> value="symbol:tapestry.DateFormat-lenient")
>   private boolean lenient;
>
>
> Date parseDate(String text) throws ParseException {
>   Date date = null;
>   if ( lenient ) {
>   date = format.parse(text);
>   } else {
>   format.setLenient(false);
>   ParsePosition parsePosition = new ParsePosition(0);
>   date = format.parse(text,parsePosition);
>   if (  parsePosition.getIndex() != text.length() ) {
>   throw new
> ParseException(messages.format("core-date-value-not-parseable"),
>   parsePosition.getErrorIndex());
>   }
>   }
>   return date;
>   }
>
> I'd like to submit this as a patch but I have the following question:
>
> What should the default for lenient be? Personally I think the default
> should be false but that's not strictly  backward compatible. So if you
> wanted the old behavior you would need to override
> tapestry.DateFormat-lenient. My thought is most people do not want the old
> behavior and are unaware DateField allows "invalid dates"
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Proposal-for-DateField-validation-patch-tp5715702.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>


Proposal for DateField validation patch

2012-08-21 Thread trsvax
After discovering DateField does not really validate dates and finding it
very difficult to make it validate I came up with the following code that I
think makes things much easier.

There are really 2 problems. 

First if you pass DateField a string for the format you get a DateFormat
with lenient set to true. This allows dates such as 00/01/2000 and
45/01/2000 because DateFormat will do it's best to turn any string into a
Date object. This means typos may be converted to a valid date and the
application cannot tell that happened.

The second problem is parse(string) just parses until it finds a valid date
and ignores trailing characters. Again this means typos slip thru for
example 01/01/200- will be the year 200 and not an error.

So I patched DateField with the following:

@Parameter(defaultPrefix = BindingConstants.PROP,
value="symbol:tapestry.DateFormat-lenient")
  private boolean lenient;


Date parseDate(String text) throws ParseException {
  Date date = null;
  if ( lenient ) {
  date = format.parse(text);
  } else {
  format.setLenient(false);
  ParsePosition parsePosition = new ParsePosition(0);
  date = format.parse(text,parsePosition);
  if (  parsePosition.getIndex() != text.length() ) {
  throw new
ParseException(messages.format("core-date-value-not-parseable"),
  parsePosition.getErrorIndex());
  }
  }
  return date;
  }

I'd like to submit this as a patch but I have the following question:

What should the default for lenient be? Personally I think the default
should be false but that's not strictly  backward compatible. So if you
wanted the old behavior you would need to override
tapestry.DateFormat-lenient. My thought is most people do not want the old
behavior and are unaware DateField allows "invalid dates"



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Proposal-for-DateField-validation-patch-tp5715702.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org