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 <[email protected]> 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 <[email protected]> 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 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
