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> > . > 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. -- 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.
