> > > 1. DateTimeFormat represents a very sophisticated API, it was > difficult > > for users to replace the formatting/parsing of dates because, to do so > they > > needed to understand the internals of the date time format class. >
Try extending DateTimeFormat rather then using the predefined constants to see this problem. > > > 2. The most desirable default parsing behavior was a hybrid between a > > DateTimeFormat + a fall back to the browser's own parsing algorithms, > this > > could not be cleanly modeled using just the DateTimeFormat. > > Where can I find this browser's own parsing algorithms in the current > code? > The default date formatter includes this code. > > > 3. When we used a template method to allow users to override the error > > reporting for date box, we still got a lot of people not finding it, > as the > > typical users looked for a setter of some flavor. > > > > I guess for 99% of usecases the default behaviour of applying an error > style to the date box is sufficient. The 1% of usecases that want to > do more sophisticated error handling should be able to override the > parse() method and catch the exception. > If I want to do my own error handling right now I have to: > Implement my own Formatter or subclass DefaultFormat anyway and > implement/override the parse method and I don't see why this is any > better than just subclassing DateBox. > People tend to look for set* methods first, so it easier for them to find the correct methods to override, the actually mechanism is the same. > > > > > > > > > > > On Tue, Jan 13, 2009 at 11:49 AM, dflorey <daniel.flo...@gmail.com> > wrote: > > > > > Seems to be a matter of taste ;-) > > > If parse() and format() should be capable of sophisticated error > > > handling (like triggering a popup to show the error or whatever) I'd > > > prefer to simply implement them as protected methods in DateBox + > > > passing DateTimeFormat to cstr instead of Format interface and let > > > user customize the behaviour by subclassing DateBox. > > > I just wanted to report that it looked strange to me at first sight > > > and as I'm totally average this also could confuse others... > > > > > On Jan 13, 5:36 pm, Ray Ryan <rj...@google.com> wrote: > > > > DateFormat isn't just a parser, nor even mainly a parser. It lets you > > > > customize the display of your datebox in response to bad input. And > > > because > > > > we pass DateBox in as a parameter, your DateFormat can be a shared > > > > flyweight. > > > > rjrjr > > > > > > On Tue, Jan 13, 2009 at 8:08 AM, dflorey <daniel.flo...@gmail.com> > > > wrote: > > > > > > > Hi, > > > > > I'm for the first time using the new 1.6 DateBox.Format feature and > I > > > > > wonder why I have to pass a DateBox to the format() and parse() > > > > > methods. > > > > > The DateBox is used in the parse method to display parsing errors. > > > > > I would prefer to let parse() throw an IllegalArgumentException > when > > > > > parsing fails and catch this exception in the enclosing parseDate() > > > > > method. This would clean up the DateBox.Format interface. > > > > > > > If you agree I can provide a tiny patch... > > > > > > > Cheers, > > > > > Daniel > > > > -- > > "There are only 10 types of people in the world: Those who understand > > binary, and those who don't" > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
