Proposal for patch to DateStringValidator

[Jake Fear <fe...@grifware.com>]

I have patched this file in my environment with the following in 
DateStringValidator.  I have added some extra-comments here to point out 
the small change.  Even though this is better, there still seems to be a 
problem.  Even though I am getting the expected results from the isValid 
calls, when I return to the page with the errors all of my values are 
cleared.  This is not consistent with other behavior I am used to seeing 
when dates are not involved.  If anyone has any ideas on that particular 
aspect, I would love to hear about them.

An alternative fix that would be slightly more lenient would be to 
change code in the same class from:

        if ((dateFormats.size() == 0) || (flexible))
        {
            df = DateFormat.getInstance();
            df.setLenient(true);
        }

to

        df = DateFormat.getInstance();
        if (flexible)
        {
            df.setLenient(true);
        }

This may allow for an unintended format (whatever DateFormat provides as 
a default) to succeed.  The solution below is somewhat more strict, 
which is why I chose it over the above solution (which was actually my 
first draft).  It does not allow unintended formats to pass.

    /**
     * Parses the String s according to the rules/formats for this
     * validator.
     */
    public Date parse(String s)
        throws ParseException
    {
        Date date = null;

        if (s == null)
        {
            throw new ParseException("Input string was null", -1);
        }

        for (int i = 0; i < dateFormats.size(); i++)
        {
            sdf.applyPattern((String)dateFormats.get(i));

            try
            {
                date = sdf.parse(s);
            }
            catch (ParseException e)
            {
                // ignore
            }

            if (date != null)
            {
                break;
            }
        }
        if ((date == null) && (df != null))
        {
            date = df.parse(s);
        }

        // Here is the added code.  If formats were provided, the df 
objects would never be initialized
        // and this final parse attempt would never run.  Since the null 
string is considered an error
        // condition, it seems consistent to consider a null date here 
an error condition.  This seems
        // to provide the expected behavior at during form submission 
except that the bogus date is
        // not retained in the field.  I'm going to look into that, but 
it is getting late ;-)
        if (date == null)
        {
            throw new ParseException("Tried every thing I could think 
of.", 0);
        }

        return date;
    }



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>