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? - Until now there were two places in Mapped(Date)(Time) where parsing occurred. setFromAny used LiftRules.parseDate, while buildSetStringValue etc. used TimeHelpers.toDate. - 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?
Thanks! ------------------------------------- Naftoli Gugenheim<[email protected]> wrote: In reverse order: Re #2, (a) that would create a two-way dependency between TimeHelpers and ConversionRules--is that desirable; (b) and thus call into question the decision to put ConversionRules in webkit not util. (c) Still, it would be an indirect branch from MappedDate etc. to ConversionRules--is there a reason? Re #1, I'm thinking maybe an even better idea is instead signatures like def format: String def parse(s: String): Unit In other words, they should deal directly with the field's state. The advantage is that it provides a future hook to deal with parsing errors similar to validation errors. Which brings me to two somewhat unrelated quesions. 1) What is the reason for 'setFromAny'? Why not overloaded methods? 2) Parsing dates with a DateFormat seems to be very brittle -- the string has to match the format exactly, e.g., if you write 1:00PM and the format string has a space before the a, it's invalid, etc.--not very user friendly. Is there a better way? ------------------------------------- Jeppe Nejsum Madsen<[email protected]> wrote: Naftoli Gugenheim <[email protected]> writes: > David and all, > QUESTION 1 > I'm working on issue #258. Here are two options for an overridable parser > (applies to formatting too): > 1. def parse(s: String): Box[Date] = ConversionRules.parseDate()(s) > 2. def parse: String=>Box[Date] = ConversionRules.parseDate() > > What are the pros and cons, and which should I use? I prefer 1) I see no reason for parse to be a function.... > QUESTION 2 > MappedDate and MappedDateTime apparently were parsing via LiftRules in > setFromAny, while buildSetStringValue etc. were using (Time)Helpers.toDate. > Is there a reason not to change it? Or, should toDate use ConversionRules? I think it would be natural for toDate to use ConversionRules....then ConversionRules becomes the only place where date formatting is handled. /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. -- 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.
