Naftoli Gugenheim <naftoli...@gmail.com> writes: > Any thoughts on this? > Basically, to restate the questions in a different way. > - I would like to add overridable methods to MappedDate/Time/DateTime, to > allow controlling the way they parse and format strings. > - Do I need a new 'format' method to controll conversion to a string? Maybe > just leverage toString?
I think toString is fine > - Until now there were two places in Mapped(Date)(Time) where parsing > occurred. setFromAny used LiftRules.parseDate, while buildSetStringValue etc. > used TimeHelpers.toDate. Should use same mechanism > - Do we need methods like setFromAny and TimeHelpers.toDate, which take an > Any and pattern match on several types of inputs? Isn't that very un-typesafe? > - Why the inconsistency between setFromAny and buildSetStringValue? Should > both use ConversionRules? Should both use toDate which should use > ConversionRules? > - Should anything in TimeHelpers use ConversionRules? (After all, > ConversionRules uses TimeHelpers, and two-way dependencies are probably > undesirable.) Should ConversionRules be in util rather than webkit? I don't know why things are as they are, but going forward, my assumption is this: - If I change date/time parsing in ConversionRules, this changes all the places where "default" date/time parsing to/from the UI takes place - I think this also goes for TimeHelpers. I see this as a higher level abstraction (the Helpers) on lower level code (ConversionRules), not the other way around - There can be still be specific date formats (ie internetDate) that is being used for API level formatting. /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
