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.
