Of course, now that I'm actually digging into the code, it really makes me want to switch to using Joda Time :). Also, the LiftRules.parseDate function currently does DateTime parsing, so I would have to make a breaking change to rename it to parseDateTime and add new parseDate and parseTime (and associated format methods). Thoughts?
Derek On Thu, Sep 10, 2009 at 1:45 PM, Naftoli Gugenheim <[email protected]>wrote: > Having an overridable toDate on the MappedXX that only defaults to the > _corresponding_ global, as Jeppe said, would provide that ability too. > Although the advantage of using a DateFormat over a def toDate is > simplicity of replacement. (Maybe it should be a function, not a method, and > there could be an implicit from DateFormat to Date=>String! :)) > > As for validation, I made myself a simple trait that holds an > Option[String] that is only Some when parsing failed, and it checks it on > validation--if it's a Some it fails--and uses it for toForm--if validation > fails the input should still hold the invalidated string, not the previous > value. > > > ------------------------------------- > Derek Chen-Becker<[email protected]> wrote: > > OK, maybe I misread Naftoli's email but it sounded like he didn't want > global parsers, e.g. a per-field parser. I agree on the Date/DateTime/Time > split. I can add some of those to LiftRules and TimeHelpers. > > Derek > > On Thu, Sep 10, 2009 at 1:04 PM, Jeppe Nejsum Madsen <[email protected] > >wrote: > > > > > Derek Chen-Becker <[email protected]> writes: > > > > > OK, this is different than the code I originally wrote. In 1.0.1 it's > > this: > > > > > > > > > http://github.com/dpp/liftweb/blob/aec338c97648ea700de7a14b495b8be6b374153b/lift-mapper/src/main/scala/net/liftweb/mapper/MappedDate.scala > > > > > > I'm not sure who made that change, but I think that we want something > in > > the > > > middle: full support for a variety of types but with user-customizable > > > parsing. I think what we really want is the original code, but changing > > the > > > toDate to a overridable def on the Field itself. Something like: > > > > > > class MappedDate ... { > > > ... > > > def parseDate(s : String) : Box[Date] = Helpers.toDate(s) > > > > > > override def setFromAny(f : Any): Date = this.parseDate(f).map(d => > > > this.set(d)).openOr(this.is) > > > ... > > > } > > > > > > Then you could provide your own if needed: > > > > > > object StartDate extends MappedDate(this) { > > > override parseDate(s: String) : Box[Date] = ... > > > } > > > > > > Thoughts? > > > > This looks like a good solution for the specific problem. But as Naftoli > > pointed out there is another issue, so I suggest that if we are going > > to change this now, I suggest we do it right. The other issues I see > > are: > > > > 1) Helpers.toDate doesn't use a locale specific date format. This can be > > set in LiftRules.parseDate. So I think LiftRules.parseDate should be > > used, either directly or from Helpers.toDate > > > > 2) MappedDate only holds a date (yymmdd), not date+time. Conversely, > > MappedTime only holds the time (hh:mm:ss), not date. Only > > MappedDateTime has both date & time. This suggest that we need a few > > more formats in LiftRules: timeFormat & dateTimeFormat as well as > > corresponding functions in TimeHelper > > > > /Jeppe > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
