RE: Proposed FormType changes

I agree that it shouldn't cause any problems...Shawn and I discussed it
quite a bit before he implemented it.

I will look at test cases and modify them if needed, and then I'll check it
in (unless someone has problems with it...then speak up!)

Christian
----------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

  -----Original Message-----
  From: [email protected]
[mailto:[email protected]]On Behalf Of Jacob Kjome
  Sent: Friday, June 13, 2003 3:13 PM
  To: [email protected]
  Subject: Re: [Barracuda] Proposed FormType changes



  Do you think the Date issues will break existing applications the same way
it broke the testcases?  Or were the testcases just being unnecessarily
stringent on the date format?  "yyyy-MM-dd" is a valid date in my book.  If
you don't forsee any (or rare) breakage of existing apps (mostly concerned
about the Date as I don't think many have started using the Timestamp yet
since it was only just introduced in 1.2.0), then I have no problem with it.
Christian or you can check it in.  Anyone else have opinions?

  Jake

  At 01:40 PM 6/13/2003 -0600, you wrote:

    Christian and I have been talking about the addition of a new FormType
for TIME and also some modifications to the existing DATE and TIMESTAMP
type. I have attached to this email a patch that includes everything we have
discussed if anyone else would like to provide some input. You can search
for saw_061203_2 to see everything that has changed.


    New FormType: TIME
    ==================
    This is a new type that allows parsing of time values without any date
component. This will return a java.sql.Time object since that is the only
representation in the core Java packages for a type that is strictly time.

    The parsing process will first try to parse as a long value
(representing the time in milliseconds)... this makes it convenient to embed
the time in a URL, for example. It will then try each of the 4 time formats
(SHORT, MEDIUM, LONG, FULL) and finally will try to parse from the SQL time
format.


    Changes to TIMESTAMP
    ====================
    Timestamp has been modified to do exactly the same parsing steps as TIME
except it will obviously be using the datetime parser
(DateFormat.getDateTimeInstance) instead of the time parser. It will return
an instance of java.sql.Timestamp (as it did before).


    Changes to DATE
    ===============
    I modified date so that it will also try the two new parsing steps
referenced above (first try to parse a long; lastly try to parse from SQL
date format). In any case it will still always return strictly a
java.util.Date object.



    Note that the changes to DATE may have broken some test cases as they
report failures on my machine (TestDateValidator and
TestDateRangeValidator). This is apparently because a date in the format
"yyyy-MM-dd" is now considered valid when it wasn't previously. Can someone
verify that?

    What does everyone else think of this?

    Thanks,
    -shawn