That actually indicates I was not correct. :) I'm not that familiar with JPA, but if your closure picks up an object with a different identity than the object it referred to, I don't see how that could be JPA's or any library's fault, or how it makes any sense for that matter unless it's a mutable field that's been written to. Where and how is user declared/defined? Is it a mutable field?
On Fri, Jan 29, 2010 at 2:05 PM, Jay Cain <[email protected]> wrote: > It seems that you are correct. My user object is a JPA entity and when > it enters the closure it has a different identityHash 10749831 vs. > 21737589. This will probably be one of many issues that I will have > to deal with if I'm going to continue with JPA? It's like the > entityManager loses reference to the entity object I persisted to the > db. That's no good. I'm starting this project from scratch and have > a java background is it easier to just pick up with Scala's persistent > architecture then continue with these little bumps in the road. > > On Jan 29, 11:06 am, Naftoli Gugenheim <[email protected]> wrote: > > And user is not a RequestVar, correct? So this is not a RequestVar > problem then? > > What is user? A JPA entity? Could this be a JPA issue? > > If you like you can use System.identityHashcode to demonstrate that the > same user instance is losing its data. > > > > ------------------------------------- > > > > Jay Cain<[email protected]> wrote: > > > > User[ id=0 email=, username = , created on=Fri Jan 29 10:57:27 MST > > 2010 role=Basic] > > > > This value I get > > > > On Jan 28, 10:44 pm, Naftoli Gugenheim <[email protected]> wrote: > > > > > > > > > You didn't answer my question. At the time the closure passed to > redirectTo is executed, what is the value of 'user'? > > > > > ------------------------------------- > > > > > Jay Cain<[email protected]> wrote: > > > > > it appears that the user still creates a new User. it is because I > > > tell it to do that each time a new request is made. > > > > > // Set up a requestVar to track the user object > > > object userVar extends RequestVar(new User()) > > > > > So I guess my question is how prevent it from doing that and still > > > pass a User object to the RequestVar I tried a RequestVar[User] but no > > > bueno > > > > > below is the snippet code for registering a user > > > > > user.password = passwordHashed > > > user.activationCode = activationCode > > > user.userProfile.user = user > > > user.userPreferences.user = user > > > Model.mergeAndFlush(user) > > > MailUtils.mailConfirmationLetter(user) > > > S.redirectTo("thank_you", () => { println(user); userVar(user);} > > > > > In the mean time I'm going to just extract the email and fullname from > > > the user and pass it as a request param > > > > > user.password = passwordHashed > > > user.activationCode = activationCode > > > user.userProfile.user = user > > > user.userPreferences.user = user > > > Model.mergeAndFlush(user) > > > MailUtils.mailConfirmationLetter(user) > > > val email = user.email > > > val fullName = user.userProfile.fullName > > > println("email " + email) > > > S.redirectTo("thank_you", () => {S.set("email", email); S.set > > > ("fullName", fullName);}) > > > > > Thanks for helping out > > > > > On Jan 27, 10:20 pm, Naftoli Gugenheim <[email protected]> wrote: > > > > > > Can you put a trace in that closure to see if 'user' has the correct > value? > > > > S.redirectTo("thank_you", () => {println(user); userVar(user);}) > > > > etc. > > > > > > On Wed, Jan 27, 2010 at 11:51 PM, Jay Cain <[email protected]> > wrote: > > > > > I think that this would work.... > > > > > > > // Set up a requestVar to track the user object > > > > > object userVar extends RequestVar(new User()) > > > > > > > S.redirectTo("thank_you", () => {userVar(user);}) > > > > > > > but no bueno. > > > > > > > On Jan 27, 4:56 pm, Naftoli Gugenheim <[email protected]> > wrote: > > > > > > When you redirect you start a new request, so RequestVars are > fresh. > > > > > > redirectTo has an overload that take additionally a function to > execute > > > > > in the new request. Set the RequestVar there. > > > > > > > > ------------------------------------- > > > > > > > > Jay Cain<[email protected]> wrote: > > > > > > > > I am a newbie to Lift and Scala. I'm registering users and once > they > > > > > > have entered the information in successfully. I want to redirect > to a > > > > > > "thank_you" page that will display a snippet > > > > > > > > <lift:UserOps.thanksMessage> > > > > > > <p> > > > > > > <entry:fullname/> thanks for joining Echo. The > > > > > > confirmation > > > > > > instructions for completing the signup process > have been > > > > > sent to > > > > > > your email address, <entry:email/> > > > > > > </p> > > > > > > </lift:UserOps.thanksMessage> > > > > > > > > I assume that when I redirect it doesn't hold the state of the > user > > > > > > information. > > > > > > > > On submit I invoke signup > > > > > > > > def signup(xhtml: NodeSeq) : NodeSeq = { > > > > > > ........ > > > > > > S.redirectTo("thank_you") > > > > > > > > } > > > > > > > > ThanksMessage function.................... > > > > > > > > def thanksMessage(xhtml: NodeSeq) : NodeSeq = { > > > > > > print("Username: " + user.username) > > > > > > bind("entry", xhtml, > > > > > > "fullname" -> Text(user.userProfile.fullName), > > > > > > "email" -> Text(user.email)) > > > > > > > > } > > > > > > > > I have declared a RequestVar object > > > > > > > > ** object userVar extends RequestVar(new User()) ** > > > > > > > > but I'm sure that it is creating an empty user object in my > RequestVar > > > > > > userVar when I redirect. > > > > > > > > Is a StatefulSnippet the solution for this? I just think that > there's > > > > > > a much simpler solution that I'm overlooking. > > > > > > > > Jay > > > > > > > > -- > > > > > > 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]<liftweb%[email protected]> > <liftweb%[email protected]<liftweb%[email protected]> > > > > > > > . > > > > > > For more options, visit this group athttp:// > > > > > 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 [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<liftweb%[email protected]> > <liftweb%[email protected]<liftweb%[email protected]> > > > > > > > . > > > > > 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 [email protected]. > > > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > > > For more options, visit this group athttp:// > 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 [email protected]. > > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > > For more options, visit this group athttp:// > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > 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 [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.
