On Mon, Nov 16, 2009 at 4:11 PM, David Pollak <[email protected]> wrote: > > > On Mon, Nov 16, 2009 at 3:10 PM, Kris Nuttycombe <[email protected]> > wrote: >> >> On Mon, Nov 16, 2009 at 4:02 PM, David Pollak >> <[email protected]> wrote: >> > >> > >> > On Mon, Nov 16, 2009 at 2:20 PM, Kris Nuttycombe >> > <[email protected]> >> > wrote: >> >> >> >> On Mon, Nov 16, 2009 at 3:13 PM, David Pollak >> >> <[email protected]> wrote: >> >> > >> >> > >> >> > On Mon, Nov 16, 2009 at 2:12 PM, Kris Nuttycombe >> >> > <[email protected]> >> >> > wrote: >> >> >> >> >> >> Hi, all, >> >> >> >> >> >> I was just informed that my changes broke MetaMegaProtoUser >> >> >> interaction. I've reverted the commit until I can get that sorted >> >> >> out. >> >> > >> >> > How was it broken? >> >> >> >> It's something to do with how the login form is processed - at the >> >> moment I haven't figured out anything more with that. Essentially, the >> >> login fails silently and returns the user to the login form upon >> >> submission. >> > >> > That sounds like a deeper issue with MetaProtoUser. I'd keep your >> > changes >> > and see why MegaProtoUser is failing. >> >> Absolutely; I just figured I didn't want to leave people with broken >> code while I figure it out since I'm not that familiar with >> MegaProtoUser and am not sure how long that will take. > > Please check the code back in and get me a test case and I'll debug it. > > I've got about 20 tickets I'm working on right now... one more ain't gonna > kill me. ;-)
Reverted my reversion. The test case is an easy one: login in hellolift displays the pathology. Thanks for your help, Kris >> >> > Also, it's best that people discuss these kinds of things on list rather >> > than contacting you privately so we can all see what's going on. >> > >> >> Totally agree. I should have made that more clear in the initial email. >> >> Kriis >> >> >> >> >> Kris >> >> >> >> > >> >> >> >> >> >> Sorry, >> >> >> >> >> >> Kris >> >> >> >> >> >> On Mon, Nov 16, 2009 at 11:27 AM, Kris Nuttycombe >> >> >> <[email protected]> wrote: >> >> >> > Hi, all, >> >> >> > >> >> >> > I have committed a number of enhancements to Loc & LocParam which >> >> >> > involves a number of breaking changes. The changes and their >> >> >> > rationale >> >> >> > is listed below. Unless you have created your own subclasses of >> >> >> > Loc >> >> >> > or >> >> >> > LocParam, these changes should not have any repercussions for you. >> >> >> > If >> >> >> > the effect of any of these changes on your particular codebase are >> >> >> > excessively disruptive, please contact me and I will work with you >> >> >> > to >> >> >> > resolve the issue. >> >> >> > >> >> >> > Breaking Changes: >> >> >> > >> >> >> > 1) LocParam >> >> >> > >> >> >> > LocParam has been made a sealed trait to facilitate pattern >> >> >> > matching >> >> >> > within the Lift codebase and has had a contravariant type >> >> >> > parameter >> >> >> > added to its type to facilitate typesafe interactions with Loc[T]. >> >> >> > The >> >> >> > new trait is hence LocParam[-T]. As LocParam is now a sealed >> >> >> > trait, I >> >> >> > have added an extension point for user-specified LocParam subtypes >> >> >> > as >> >> >> > UserLocParam[-T] extends LocParam[T]. Since the new type parameter >> >> >> > is >> >> >> > contravariant, LocParam subclasses that are applicable for any >> >> >> > Loc[T] >> >> >> > have the type LocParam[Any], and a type alias AnyLocParam has been >> >> >> > added for this type. >> >> >> > >> >> >> > The Loc.checkProtected method now enforces type consistency >> >> >> > between >> >> >> > the evaluated Link[T] and the list of LocParam[T] which are used >> >> >> > to >> >> >> > evaluate whether the link is accessible given the specified >> >> >> > parameters. >> >> >> > >> >> >> > 2) Renames >> >> >> > >> >> >> > Previously, the "Param" suffix was used for two unrelated purposes >> >> >> > within Loc: first, to refer to the type parameter of the Loc, and >> >> >> > secondly for the LocParam configuration. This overloading made the >> >> >> > code and the API somewhat difficult to read, so the first usage >> >> >> > has >> >> >> > been removed resulting in the following renames: >> >> >> > >> >> >> > ParamType => T >> >> >> > NullLocParams => //removed, Unit is sufficient! >> >> >> > Loc.defaultParams => Loc.defaultValue >> >> >> > Loc.forceParam => Loc.overrideValue >> >> >> > Loc.foundParam => Loc.requestValue >> >> >> > Loc.additionalKidParams => Loc.childValues >> >> >> > >> >> >> > After this change, all instances of the "param" name within Loc >> >> >> > should >> >> >> > refer to something having to do with LocParam instances. >> >> >> > >> >> >> > Non-Breaking Additions: >> >> >> > >> >> >> > case class IfValue[T](test: Box[T] => Boolean, failMsg: FailMsg) >> >> >> > extends LocParam[T] >> >> >> > case class UnlessValue[T](test: Box[T] => Boolean, failMsg: >> >> >> > FailMsg) >> >> >> > extends LocParam[T] >> >> >> > case class TestValueAccess[T](func: Box[T] => Box[LiftResponse]) >> >> >> > extends LocParam[T] >> >> >> > >> >> >> > If you are using a non-Unit typed Loc, you can use these LocParam >> >> >> > instances to enforce access rules at the value level. >> >> >> > >> >> >> > case class ValueTemplate[T](template: Box[T] => NodeSeq) extends >> >> >> > LocParam[T] //per-value template selection >> >> >> > >> >> >> > DataLoc[T] subclass of Loc was added to facilitate the use of the >> >> >> > new >> >> >> > more typeful LocParam subtypes. >> >> >> > >> >> >> > A few changes to Link: >> >> >> > >> >> >> > Since Link.createLink creates a Box[Text] (and not a clickable >> >> >> > link) >> >> >> > a >> >> >> > couple of methods were added to create the intermediate, unboxed >> >> >> > values in order that subclasses can more easily manipulate the >> >> >> > resulting >> >> >> > path: >> >> >> > >> >> >> > Link.pathList(value: T): List[String] // added to facilitate >> >> >> > creation >> >> >> > of value-aware paths by subclasses. >> >> >> > Link.createPath(value: T): String //creates the String >> >> >> > representation >> >> >> > of the path that is subsequently turned into XML and boxed by >> >> >> > Link.createLink >> >> >> > >> >> >> > Again, please let me know if any of these changes cause you >> >> >> > headaches! >> >> >> > My hope is that much of the modified functionality has not been >> >> >> > used >> >> >> > by very many people yet and that as a result it's a good time to >> >> >> > make >> >> >> > these changes before typeful Locs get too widely used to make >> >> >> > breaking >> >> >> > changes. >> >> >> > >> >> >> > Thanks, >> >> >> > >> >> >> > Kris >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > 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 >> > >> > > >> > >> >> > > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
