Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-14 Thread Naftoli Gugenheim
Pretty please? On Fri, Feb 12, 2010 at 2:36 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: (FYI: buildSetXXValue methods are called when loading the field from the database in MetaMapper.scala. This question is relevant in the context of a Mapped(Date)(Time) that corresponds to a database

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-12 Thread Naftoli Gugenheim
(FYI: buildSetXXValue methods are called when loading the field from the database in MetaMapper.scala. This question is relevant in the context of a Mapped(Date)(Time) that corresponds to a database column with a char-based type.) If the toDate calls in buildSetXXValue are to be replaced with the

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-10 Thread Jeppe Nejsum Madsen
Naftoli Gugenheim naftoli...@gmail.com writes: At what would make sense to move around, i.e., what I should to move #257 and #258 forward. Thanks! I think those look good. In the spirit of incremental progress, I think any other changes should be on new tickets. /Jeppe -- You received

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-10 Thread Naftoli Gugenheim
So are you saying to leave buildSetFromString pointing to Helpers.toDate for the time being? - Jeppe Nejsum Madsenje...@ingolfs.dk wrote: Naftoli Gugenheim naftoli...@gmail.com writes: At what would make sense to move around, i.e., what I should to move

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-10 Thread Jeppe Nejsum Madsen
On Wed, Feb 10, 2010 at 9:02 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: So are you saying to leave buildSetFromString pointing to Helpers.toDate for the time being? I'm not sure I follow? I can't find buildSetFromString (in master) anywhere and the setFromAny that covers string seem to

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-10 Thread Naftoli Gugenheim
Sorry, type: I was referring to this: def buildSetActualValue(accessor: Method, v: AnyRef, columnName: String): (T, AnyRef) = Unit = (inst, v) = doField(inst, accessor, {case f: MappedDate[_] = f.st (toDate(v))}) def buildSetLongValue(accessor: Method, columnName: String): (T, Long,

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-10 Thread Naftoli Gugenheim
In Mapped(Date)(Time) And 'type' was also a typo. :) On Wed, Feb 10, 2010 at 5:21 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: Sorry, type: I was referring to this: def buildSetActualValue(accessor: Method, v: AnyRef, columnName: String): (T, AnyRef) = Unit = (inst, v) =

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-10 Thread Jeppe Nejsum Madsen
Ahh ok. It's getting late and I'm perhaps not thinking straight but I think TimeHelpers.toDate should go through ConversionRules. This may cause circular deps etc. in which case I think buildSetStringValue should go through ConversionRules. I don't know mapper internals good enough to really see

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-10 Thread Naftoli Gugenheim
- 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

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-09 Thread Naftoli Gugenheim
Wait--are you saying TimeHelpers should use ConversionRules and ConversionRules should *not* reference TimeHelpers? If so it would involve a lot of refactoring, although I think I hear where you're coming from. I'll try to push the wip-nafg-date branch a bit later. What time zone are you in?

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-09 Thread Naftoli Gugenheim
It would be really great if you could take a look at TimeHelpers and my diff (vs. original), on RB and wip-nafg-date. I asked about your time zone only because I was wondering if you'd be around when I pushed it, but it's pushed. - Jeppe Nejsum

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-07 Thread Naftoli Gugenheim
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

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-05 Thread Jeppe Nejsum Madsen
Naftoli Gugenheim naftoli...@gmail.com 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] =

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-05 Thread Indrajit Raychaudhuri
On 05/02/10 5:28 PM, Jeppe Nejsum Madsen wrote: Naftoli Gugenheimnaftoli...@gmail.com 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)

[Lift] Mapped(Date)(Time) formatter/parser

2010-02-04 Thread Naftoli Gugenheim
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