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 <[email protected]>wrote: > > 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 > <[email protected]> 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 < > [email protected]> > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
