I've got negative available time. Sorry. On Mon, Aug 10, 2009 at 1:28 PM, Naftoli Gugenheim <[email protected]>wrote:
> > It looks like some ".is"'s need to be explicit. I wonder if the implicit > doesn't apply now that it's using member types? > David, if you choose to volunteer to add .is to references to > primaryKeyField it will get on github sooner than if I do it, but I can do > it if you don't. > > > ------------------------------------- > glenn<[email protected]> wrote: > > > David, > > I'm using your new ManyToMany trait and ran across this error: > > Message: java.lang.ClassCastException: net.liftweb.mapper.ProtoUser$id > $ cannot be cast to java.lang.Long > scala.runtime.BoxesRunTime.unboxToLong(Unknown Source) > net.liftweb.mapper.MappedLong.real_i_set_$bang(MappedLong.scala:223) > net.liftweb.mapper.MappedField$class.i_set_$bang(MappedField.scala: > 449) > net.liftweb.mapper.MappedLong.i_set_$bang(MappedLong.scala:223) > net.liftweb.mapper.MappedField$class.set(MappedField.scala:429) > net.liftweb.mapper.MappedLong.set(MappedLong.scala:223) > net.liftweb.mapper.ManyToMany$MappedManyToMany.own(ManyToMany.scala: > 78) > > My code that generates the error is: > > entity.roles += r > > where entity is a User and roles is the MappedManyToMany object in > User. > > Glenn... > > > On Aug 8, 10:35 pm, Naftoli Gugenheim <[email protected]> wrote: > > Thanks, David. > > Glenn, as far as the issue of adding unsaved children, I was thinking > about it. If the same Role can be referenced by multiple users, why are you > creating Roles at the same time that you are adding them to a User? > Shouldn't there be one screen to manage Roles and the User screen would only > allow you to add existing Roles? > > > > ------------------------------------- > > > > David Pollak<[email protected]> wrote: > > > > There are dependent types that mirror the parameterized types for Mapper, > > KeyedMapper, etc. > > I've updated ManyToMany to use the dependent types... it should eliminate > > the need to have the type parameters. If it breaks thing, please revert > the > > changes. > > > > On Thu, Aug 6, 2009 at 9:55 AM, Naftoli Gugenheim <[email protected] > >wrote: > > > > > In your use case it can only be Long and User. But there has to be a > type > > > parameter because other people might have a String key and a Request > mapper. > > > And the contents of ManyToMany have to be type safe to enforce their > > > consistency with however the user of ManyToMany wants them to use it. > So I > > > think what you want is that the compiler should figure out that since > you're > > > using it with a KeyedMapper[Long, User], which is ManyToMany's T <: > > > KeyedMapper[K,T], and ManyToMany extends KeyedMapper[K,T] and it has a > self > > > type of T, and therefore it would be a compiler error to write anything > > > besides Long and User, therefore you must want to use Long and User and > they > > > should be inferred. > > > I could certainly hear that, although I'm not much of a type theorist. > So > > > feel free to open an enhancement ticket on Scala's Trac! :) > > > If I understood correctly... > > > > > On Thu, Aug 6, 2009 at 12:43 PM, glenn <[email protected]> wrote: > > > > >> Naftoli, > > > > >> As I said at the outset, this is really beyond my expertise. But I > > >> think it's too > > >> broad and maybe, even unnecessary. In my example, K can only be one > > >> type, > > >> Long, and T can only be of type User. Anything else, and the compiler > > >> can't be > > >> guaranteed to catch it, but try running the application and you get > > >> things like > > >> stack overflow errors. > > > > >> How you would fix this is beyond me. All you can really do, at this > > >> point, is > > >> make sure to include these kinds of restrictions in the docs. > > > > >> Glenn... > > > > >> On Aug 6, 9:33 am, Naftoli Gugenheim <[email protected]> wrote: > > >> > It's too broad, or it's too restrictive/unnecessary? I'm confused, > you > > >> seem > > >> > to imply both.If it's too broad, tell me why. But if you want to > know > > >> why it > > >> > needs the type parameter, it's because it has to use the type > parameter > > >> in > > >> > its implentation -- just count how many times its source code uses > it! > > >> And > > >> > if you want to know why the compiler can't infer it or be told to > infer > > >> > it... that's another issue. > > >> > But if passing a type that creates a conflicting inheritance causes > a > > >> > compiler crash, that's not something I can help. :) > > >> > Regards. > > > > >> > On Thu, Aug 6, 2009 at 12:26 PM, glenn <[email protected]> wrote: > > > > >> > > Naftoli, > > > > >> > > At the risk of discussing something obviously beyond my pay grade, > > >> > > isn't the real issue Scala traits > > >> > > and the use of parameterized types. The ManyToMany trait is > defined > > >> > > as: > > > > >> > > trait ManyToMany[K,T<:KeyedMapper[K, T]].... > > > > >> > > But this isn't really correct,is it, the parameter is too broad, > and > > >> > > that leads to a lot of the confusion and results in the need for > > >> > > unnecessary documentation. When you think about it, why all the > > >> > > duplication? Why do I need to > > >> > > write my User entity as: > > > > >> > > class User extends MegaProtoUser[User] with ManyToMany[Long,User] > > > > >> > > when we all know that this would be much cleaner: > > > > >> > > class User extends MegaProtoUser[User] with ManyToMany. > > > > >> > > But traits aren't like interfaces. They have implementation and > would > > >> > > need to know something about > > >> > > the parent class they are attached to - and how would you > accomplish > > >> > > that (reflection, maybe). This is > > >> > > more a Scala issue than a Lift one, I think. > > > > >> > > Glenn... > > > > >> > > On Aug 5, 8:24 pm, Naftoli Gugenheim <[email protected]> > wrote: > > >> > > > Building causes a stack overflow? > > >> > > > So the question is, is it the resident compiler or plain scalac > also > > >> > > crashes? Or just the presentation compiler? What do you see in the > > >> error log > > >> > > view or file? > > >> > > > I get compiler crashes very often when doing fancy mapper type > > >> related > > >> > > tricks. > > > > >> > > > ------------------------------------- > > > > >> > > > glenn<[email protected]> wrote: > > > > >> > > > Naftoli, > > > > >> > > > Hate to do this to you, but I'm getting the following error > using > > >> > > > ManyToMany for Users to Roles: > > > > >> > > > Message: java.lang.RuntimeException: Broken join > > >> > > > scala.Predef$.error(Predef.scala:76) > > > > >> > > > net.liftweb.mapper.ManyToMany$MappedManyToMany$$anonfun$children$1$ > > >> > > > $anonfun$apply$1.apply(ManyToMany.scala:54) > > > > >> > > > net.liftweb.mapper.ManyToMany$MappedManyToMany$$anonfun$children$1$ > > >> > > > $anonfun$apply$1.apply(ManyToMany.scala:54) > > >> > > > net.liftweb.util.EmptyBox.openOr(Box.scala:372) > > > > >> net.liftweb.mapper.ManyToMany$MappedManyToMany$$anonfun$children > > >> > > > $1.apply(ManyToMany.scala:54) > > > > >> net.liftweb.mapper.ManyToMany$MappedManyToMany$$anonfun$children > > >> > > > $1.apply(ManyToMany.scala:54) > > >> > > > scala.List.map(List.scala:812) > > >> > > > net.liftweb.mapper.ManyToMany$MappedManyToMany.children > > >> > > > (ManyToMany.scala:54) > > >> > > > net.liftweb.mapper.ManyToMany$MappedManyToMany.elements > > >> > > > (ManyToMany.scala:96) > > >> > > > scala.Seq$class.flatMap(Seq.scala:293) > > >> > > > net.liftweb.mapper.ManyToMany$MappedManyToMany.flatMap > > >> > > > (ManyToMany.scala:44) > > > > >> > > > def edit(ns: NodeSeq): NodeSeq = { > > >> > > > val theUser = view.entity > > >> > > > val addRole = TheBindParam("insert", > view.snippet.link("edit", > > >> () > > >> > > > => theUser.roles += new Role, Text(S?("Add Role")))) > > > > >> > > > bind("user", ns, > > >> > > > "firstname" -> text(theUser.firstName.is, > > >> theUser.firstName > > >> > > > (_), ("size","20")), > > >> > > > "lastname" -> text(theUser.lastName.is > > >> ,theUser.lastName(_), > > >> > > > ("size", "30")), > > >> > > > "roles" -> theUser.roles.flatMap{role => > > >> > > > bind("role", ns, > > >> > > > "name" -> role.name.toForm, > > >> > > > "remove" -> SHtml.submit(S?("Remove"), ()=> > > >> > > > theUser.roles -= role) > > >> > > > ) > > >> > > > }, > > >> > > > addRole, > > >> > > > "submit" -> SHtml.submit(S?("Save"), ()=>view.save) > > >> > > > ) > > >> > > > } > > > > >> > > > The offending code seems to be the line: "roles" -> > > >> > > > theUser.roles.flatMap{.... > > >> > > > in the above bind method when I click on the addRole link. > > > > >> > > > Here's my User class: > > > > >> > > > class User extends MegaProtoUser[User] with > ManyToMany[Long,User]{ > > >> > > > def getSingleton = User // what's the "meta" server > > > > >> > > > object roles > > >> > > > extends MappedManyToMany(UserRole, UserRole.user, > UserRole.role, > > >> > > > Role) > > > > >> > > > } > > > > >> > > > What am I doing wrong? You can see how difficult it is to slog > > >> through > > >> > > > this code, let alone just > > >> > > > trying to explain the problem so I can get help. > > > > >> > > > On Aug 5, 9:57 am, Naftoli Gugenheim <[email protected]> > wrote: > > > > >> > > > > I'll try. > > >> > > > > By the way, as per my correction, you can implement list the > > >> regular > > >> > > way without ModelView, and just use ModelSnippet's load function > in > > >> your > > >> > > edit link or button, passing it the User instance. > > > > >> > > > > ------------------------------------- > > > > >> > > > > glenn<[email protected]> wrote: > > > > >> > > > > Naftoli, > > > > >> > > > > I fixed my code per your comments and now I can edit and > remove > > >> users > > >> > > > > from a list, as long as I populate the list with > > >> > > > > ModelView instances, as you said. As for the docs, this step > was > > >> not > > >> > > > > clear to me at all. I just assumed that the list was > > >> > > > > just populated with User entities and the view in the > ModelSnippet > > >> was > > >> > > > > instantiated with the selected User on each request. > > > > >> > > > > It sounds like your plate is pretty full, so I won't expect > much, > > >> but > > >> > > > > sometime soon, could you provide an example, or improved > > >> > > > > docs, for using TableEditor and its related ItemsList trait. > > > > >> > > > > Thanks for all. > > > > >> > > > > Glenn... > > > > >> > > > > On Aug 5, 9:18 am, Naftoli Gugenheim <[email protected]> > > >> wrote: > > > > >> > > > > > Correction: ModelSnippet.load takes the actual Mapper > instance, > > >> not > > >> > > the ModelView wrapper. > > > > >> > > > > > ------------------------------------- > > > > >> > > > > > Naftoli Gugenheim<[email protected]> wrote: > > > > >> > > > > > To answer your immediate question, the listing should not > refer > > >> to > > >> > > the snippet's view but new ModelView instances for each entity. > Then > > >> > > editAction is shorthand for the snippet's link method with a > callback > > >> to > > >> > > call load on the ModelView. To set the snippet's view's entity, > either > > >> call > > >> > > load on the snippet with the other ModelView, or call load on the > > >> other > > >> > > ModelView (or just set its entity directly). > > >> > > > > > As far as documentation, please tell me what scaladocs need > what > > >> > > clarification. Thanks. > > > > >> > > > > > ------------------------------------- > > > > >> > > > > > glenn<[email protected]> wrote: > > > > >> > > > > > Naftoli, > > > > >> > > > > > Functional programming systems are notoriously difficult to > > >> document. > > > > ... > > > > read more ยป > > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
