Re: [Lift] The role of LiftRules
When are the implicits on a companion object invoked without needing to be imported? - Jeppe Nejsum Madsen wrote: Naftoli Gugenheim writes: > Would it be a bad idea to use java.util.Date for now, and if and when support > is added for JodaTime, change it to a DateHolder (which would be added then)? Haven't looked in detail, but wouldn't this require two changes to client code? 1) One to use the new ConversionRules 2) One when DateHolder is introduced If so, I suggest we take the hit now to allow for a seamless (if such a thing exists :-) change to JodaTime /Jeppe -- 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.
Re: [Lift] The role of LiftRules
See David's last post on this thread, and the updated diff on RB. - Jeppe Nejsum Madsen wrote: Naftoli Gugenheim writes: > Would it be a bad idea to use java.util.Date for now, and if and when support > is added for JodaTime, change it to a DateHolder (which would be added then)? Haven't looked in detail, but wouldn't this require two changes to client code? 1) One to use the new ConversionRules 2) One when DateHolder is introduced If so, I suggest we take the hit now to allow for a seamless (if such a thing exists :-) change to JodaTime /Jeppe -- 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.
Re: [Lift] The role of LiftRules
Naftoli Gugenheim writes: > Would it be a bad idea to use java.util.Date for now, and if and when support > is added for JodaTime, change it to a DateHolder (which would be added then)? Haven't looked in detail, but wouldn't this require two changes to client code? 1) One to use the new ConversionRules 2) One when DateHolder is introduced If so, I suggest we take the hit now to allow for a seamless (if such a thing exists :-) change to JodaTime /Jeppe -- 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.
Re: [Lift] The role of LiftRules
Would it be a bad idea to use java.util.Date for now, and if and when support
is added for JodaTime, change it to a DateHolder (which would be added then)?
-
David Pollak wrote:
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 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 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 >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
Re: [Lift] The role of LiftRules
Sounds good!
-
David Pollak wrote:
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 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 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 >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
>
> >
> > .
> > For more options, visit this group at
> > http://groups.google.com/group/liftweb?hl=en.
> >
>
>
>
> --
> L
Re: [Lift] The role of LiftRules
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 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 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 >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
>
> >
> > .
> > 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 S
Re: [Lift] The role of LiftRules
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 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 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 > . > 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.
Re: [Lift] The role of LiftRules
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 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 > . > 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.
Re: [Lift] The role of LiftRules
We were talking in another thread about having something kind of similar to this where the configuration is held in lift-util (maybe lift-common) but it is accessible through LiftRules. I think it could be a good idea to do this for this as well, to help guide people to the right place for this configuration. -Ross On Feb 25, 2010, at 10:01 PM, Naftoli Gugenheim 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. > 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.
[Lift] The role of LiftRules
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. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
