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.

Reply via email to