A ConversionRules singleton is the wrong concept.
What you want is:
case class DateHolder(date: JodaTime) {
implicit def asJt: JodaTime = date
implicit def asJavaDate: java.util.Date = // convert to Java date here
}
object DateHolder {
implicit def dateToDH(in: java.util.Date): DateHolder = ...
implicit def jtToDH(in: JodaTime): DateHolder = new DateHolder(in)
}
trait DateTimeConverter {
def formatDate(in: DateHolder): String
def formatTime(in: DateHodler): String
...
def parseDate(in: String): Box[DateHolder]
def parseTime(in: String): Box[DateHolder]
...
}
in util:
object DateTimeConverter {
def vend(locale: java.util.Locale): DateTimeConverter = build/cache locale
specific converters here
}
So, we've addressed the JodaTime vs. java.util.Date issue. Next we hook
things up to LiftRules:
LiftRules {
val dateTimeConverter = new FactoryMaker[DateTimeConverter](() =>
DateTimeConverter.vend(S.locale))
}
Make sense?
On Fri, Feb 26, 2010 at 1:54 PM, Naftoli Gugenheim <naftoli...@gmail.com>wrote:
> Oh, right--I forgot about per-session and request.
> So what do you vote on this, then:
> A. ConversionRules is its own singleton, but as a bonus it can also be
> accessed from LiftRules.
> B. Same as A but ConversionRules is private[liftweb], so there's only one
> path.
> C. Less redundant: define (a renamed) ConversionRules inside LiftRules
> D. Make ConversionRules a class with immutable vals, and LiftRules will
> have a ConversionRules FactoryMaker. We can provide several default
> ConversionRules instances. This makes it easier to have preset
> configurations switched all at a time, which is a very reasonable thing to
> want to do. (At some point there could be a JodaTime instance maybe...) This
> also allows putting ConversionRules in lift-util while still having the
> benefits of FactoryMaker.
> Personally D sounds the best but I'm open to whatever others want.
>
> -------------------------------------
> David Pollak<feeder.of.the.be...@gmail.com> wrote:
>
> The basic DI (the stuff Factory/FactoryMaker are built on) are located in
> util: see Maker.scala
>
> The Factory stuff is in webkit because it relies on session and request
> state. You can change the rules for vending something on a
> session-by-session and request-by-request basis.
>
> LiftRules is the single locus of setting webkit rules. There should be one
> and only one. Before Marius came along and put everything in one place,
> webkit was a mess of configuration singletons. I support his design and
> think it has held up well. People know where to set webkit related stuff.
>
> As much as possible, we try not to allow the stuff in util to have mutable
> state/settings. Why? Because the stuff in util should always behave the
> same way: predictably.
>
> But the date/time stuff transcends webkit... it should be generically
> useful
> across non-webkit applications.
>
> At this point, I think the easiest answer is to put the date/time stuff in
> webkit until there's a better answer. The locus of configuration for
> webkit
> stuff is LiftRules, so the date/time configuration should live there.
>
> On Thu, Feb 25, 2010 at 7:01 PM, Naftoli Gugenheim <naftoli...@gmail.com
> >wrote:
>
> > Hi, I'd like to get some opinions on the following.
> > You may want to read http://reviewboard.liftweb.net/r/158/.
> >
> > I have on Review Board a patch for some date-and-time parsing and
> > formatting configuration. I put the settings inside a singleton object
> > called ConversionRules.
> > The question is, where do these configurations belong?
> > Marius feels that LiftRules is the place where people look for all
> > Lift-related configuration. So that the LiftRules code shouldn't become
> too
> > monstrous, it makes sense to put the code in ConversionRules and have a
> val
> > in LiftRules pointing to ConversionRules.
> > My opinion is that LiftRules is, at least for the most part, http-
> > (lift-webkit) related, and should be that way. I would actually prefer to
> > ConversionRules in lift-util, but it relies on Factory which is in
> webkit.
> > Preferably Factory could be moved to lift-util and ConversionRules with
> it.
> > Now I suppose pointing LiftRules to ConversionRules is possible even if
> the
> > latter is moved to lift-util, so I guess it really boils down to whether
> it
> > would be beneficial for ConversionRules to be presented as "side by side"
> > with LiftRules, or as a member of it. (If the latter, I suppose
> > ConversionRules could be made private[liftweb] so there's only one path
> to
> > it...)
> > Thoughts?
> > Thanks!
> >
> > --
> > 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<liftweb%2bunsubscr...@googlegroups.com>
> <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@googlegroups.com>
> >
> > .
> > For more options, visit this group at
> > http://groups.google.com/group/liftweb?hl=en.
> >
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> 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<liftweb%2bunsubscr...@googlegroups.com>
> .
> 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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
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.
