[Lift] Re: Playing around with Loc
Kris,
This all looks very good to me. Unless others object, please open a ticket
(nothing going into Lift without a ticket... the tyranny of process). Let's
roll this stuff in post M7. Also, please prepare an email to send to this
list and the Lift-announce list with the breaking changes.
Thanks,
David
On Sat, Oct 24, 2009 at 4:49 PM, Kris Nuttycombe
kris.nuttyco...@gmail.comwrote:
My motivation was twofold: first, I wanted to be able to control
access to a Loc based upon the data in the Loc itself (hence the new
IfValue and UnlessValue) and in the process I realized that there was
a disconnect in type safety between for example the Title LocParam and
the Loc itself because there was no enforcement that a LocParam added
to the Loc would respect the Loc's type. Secondly, I have found it
useful to have a construct like the following:
object Site {
var locs: List[Loc[_]] = Nil
def add[T](l: Loc[T]): Loc[T] = {
locs = l :: locs
l
}
val userLoc = add(new DataLoc[User](...))
val orderLoc = add(new DataLoc[Order](...))
}
Then, in my Boot.scala I create the SiteMap like this:
LiftRules.setSiteMap(SiteMap(Site.locs.map(Menu(_)): _*))
The advantage of this construction is that I can refer to userLoc or
orderLoc from anywhere in my application and can use the Locs to
create links to display pages for various objects in a typesafe
fashion.
The main breaking change is a rename of defaultParams to defaultValue,
which I did mostly in the process of trying to understand the code
better, since it took me a few minutes at first to figure out the dual
use of the Param.
It also occurred to me that instead of adding the type parameter
directly to LocParam and adding the AnyLocParam name for
LocParam[Nothing], it would be just as easy to add a new parameterized
supertrait of LocParam which would break less code.
As far as sealing the trait goes, I've been bitten twice recently by
production bugs due to an incomplete match, so I figure that sealing
could be helpful so long as there's a well-known extension point for
user additions.
Kris
On Sat, Oct 24, 2009 at 5:18 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
In general, it all sounds very good to me.
What was your motivation (other than pure aesthetics)?
If there are breaking changes to code, will they be super-obvious
(compilation failures)?
On Fri, Oct 23, 2009 at 5:04 PM, Kris Nuttycombe
kris.nuttyco...@gmail.com
wrote:
Hi, all,
I've been messing around with Loc a bit to try to tighten up the type
safety of the parameterized type and add authentication LocParams that
can be aware of the current value encapsulated by the Loc. I've put up
some changes on the kjn-loc-wip branch and would really like some
feedback.
Some of the major changes:
* gave LocParam a covariant type parameter to go with Loc's type
parameter and made it a sealed trait, with UserLocParam[T] as the main
extension point for user-defined traits. Added AnyLocParam as base
trait of LocParam instances that are not dependent upon T
* Added IfValue UnlessValue LocParams
* Made default Loc parameterized by Unit instead of NullLocParams
* Some minor renaming to distinguish between uses of the Param name-
- now all Param usages refer to LocParams
* Removed need for a bunch of asInstanceOf casts
What do you all think? Is this something that you'd like to see
cleaned up committed to master?
Thanks,
--
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
--
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 liftweb@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] Re: Playing around with Loc
In general, it all sounds very good to me. What was your motivation (other than pure aesthetics)? If there are breaking changes to code, will they be super-obvious (compilation failures)? On Fri, Oct 23, 2009 at 5:04 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: Hi, all, I've been messing around with Loc a bit to try to tighten up the type safety of the parameterized type and add authentication LocParams that can be aware of the current value encapsulated by the Loc. I've put up some changes on the kjn-loc-wip branch and would really like some feedback. Some of the major changes: * gave LocParam a covariant type parameter to go with Loc's type parameter and made it a sealed trait, with UserLocParam[T] as the main extension point for user-defined traits. Added AnyLocParam as base trait of LocParam instances that are not dependent upon T * Added IfValue UnlessValue LocParams * Made default Loc parameterized by Unit instead of NullLocParams * Some minor renaming to distinguish between uses of the Param name- - now all Param usages refer to LocParams * Removed need for a bunch of asInstanceOf casts What do you all think? Is this something that you'd like to see cleaned up committed to master? Thanks, -- 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 liftweb@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] Re: Playing around with Loc
My motivation was twofold: first, I wanted to be able to control
access to a Loc based upon the data in the Loc itself (hence the new
IfValue and UnlessValue) and in the process I realized that there was
a disconnect in type safety between for example the Title LocParam and
the Loc itself because there was no enforcement that a LocParam added
to the Loc would respect the Loc's type. Secondly, I have found it
useful to have a construct like the following:
object Site {
var locs: List[Loc[_]] = Nil
def add[T](l: Loc[T]): Loc[T] = {
locs = l :: locs
l
}
val userLoc = add(new DataLoc[User](...))
val orderLoc = add(new DataLoc[Order](...))
}
Then, in my Boot.scala I create the SiteMap like this:
LiftRules.setSiteMap(SiteMap(Site.locs.map(Menu(_)): _*))
The advantage of this construction is that I can refer to userLoc or
orderLoc from anywhere in my application and can use the Locs to
create links to display pages for various objects in a typesafe
fashion.
The main breaking change is a rename of defaultParams to defaultValue,
which I did mostly in the process of trying to understand the code
better, since it took me a few minutes at first to figure out the dual
use of the Param.
It also occurred to me that instead of adding the type parameter
directly to LocParam and adding the AnyLocParam name for
LocParam[Nothing], it would be just as easy to add a new parameterized
supertrait of LocParam which would break less code.
As far as sealing the trait goes, I've been bitten twice recently by
production bugs due to an incomplete match, so I figure that sealing
could be helpful so long as there's a well-known extension point for
user additions.
Kris
On Sat, Oct 24, 2009 at 5:18 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
In general, it all sounds very good to me.
What was your motivation (other than pure aesthetics)?
If there are breaking changes to code, will they be super-obvious
(compilation failures)?
On Fri, Oct 23, 2009 at 5:04 PM, Kris Nuttycombe kris.nuttyco...@gmail.com
wrote:
Hi, all,
I've been messing around with Loc a bit to try to tighten up the type
safety of the parameterized type and add authentication LocParams that
can be aware of the current value encapsulated by the Loc. I've put up
some changes on the kjn-loc-wip branch and would really like some
feedback.
Some of the major changes:
* gave LocParam a covariant type parameter to go with Loc's type
parameter and made it a sealed trait, with UserLocParam[T] as the main
extension point for user-defined traits. Added AnyLocParam as base
trait of LocParam instances that are not dependent upon T
* Added IfValue UnlessValue LocParams
* Made default Loc parameterized by Unit instead of NullLocParams
* Some minor renaming to distinguish between uses of the Param name-
- now all Param usages refer to LocParams
* Removed need for a bunch of asInstanceOf casts
What do you all think? Is this something that you'd like to see
cleaned up committed to master?
Thanks,
--
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 liftweb@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] Re: Playing around with Loc
On Sat, Oct 24, 2009 at 5:18 PM, David Pollak feeder.of.the.be...@gmail.com wrote: In general, it all sounds very good to me. What was your motivation (other than pure aesthetics)? If there are breaking changes to code, will they be super-obvious (compilation failures)? Oh... and yeah, replacing NullLocParams with Unit was purely aesthetic. :) Kris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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 -~--~~~~--~~--~--~---
