Re: [Lift] The role of LiftRules
See David's last post on this thread, and the updated diff on RB. - Jeppe Nejsum Madsenje...@ingolfs.dk wrote: Naftoli Gugenheim naftoli...@gmail.com 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
When are the implicits on a companion object invoked without needing to be imported? - Jeppe Nejsum Madsenje...@ingolfs.dk wrote: Naftoli Gugenheim naftoli...@gmail.com 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
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 Pollakfeeder.of.the.be...@gmail.com 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 naftoli...@gmail.comwrote:
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 Pollakfeeder.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
Re: [Lift] The role of LiftRules
Naftoli Gugenheim naftoli...@gmail.com 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
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 Pollakfeeder.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.comwrote: 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.comliftweb%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.
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 naftoli...@gmail.comwrote:
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 Pollakfeeder.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.comliftweb%2bunsubscr...@googlegroups.com
liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply
Re: [Lift] The role of LiftRules
Sounds good!
-
David Pollakfeeder.of.the.be...@gmail.com 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 naftoli...@gmail.comwrote:
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 Pollakfeeder.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.comliftweb%2bunsubscr...@googlegroups.com
liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com
.
For more
[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.
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.
