Passing objects with RequestVar via GET request

[Sergey Trofimov]

Greetings to all.

Is it generally possible to use RequestVar (or TransientRequestVar) to pass objects across multiple requests by adding corresponding GET parameters manually?

If yes, how should we calculate corresponding GET-param to add it to the links?

Thank you.

[Timothy Perrett]

Sergey, can you clarify your question some more? Are you redirecting or something? Possibly this could be what you want:

redirectTo [T] (where: String, func: () ⇒ Unit) : T

Cheers, Tim

[Ján Raska]

Hi Sergey,
why would you want to do that? I think concept of RequestVar is different from concept of request params, at least in a sense, that RequestVar can hold basically any type, while request params are only Strings. Not to mention, that it's not a good idea to pass large data over GET due to several reasons.

If you just need to make sure that data are available for multiple requests within the same session, use SessionVar, if you need them available for multiple AJAX requests within same page, then RequestVar is all you need.

But please, tell us your use case, then we'll be able to help you better.

Jan

> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Sergey Trofimov]

Well, my task is following:

1. I need to generate a link to remote authorization service (the Orkut in the case). [It′a a page 1]
   
2. I should specify callback link this generating this link.
3. On callback page I need to verify parameters received from remote authorization service. [It′s a page 2]
   

On step 1 and 2 I need to use same instance of the object which generate (see 1.) and verify callback params (see 2.) (the DefaultOrkutAdapter). Otherwise step 3 always fail.

My current working solution is:

• Create the object in step 1
• Keep the object in SessionVar
• Pass jsessionid in callback link
• Reuse the object in step 2
• Using “object” instead of “class” does not work here because it cannot be shared between clients.

But I know that lift can pass objects between request using special inputs in forms etc.
So my alternate idea is to add similar param to my callback link manually so that I can reuse object via standard RequestVar mechanism.

[Timothy Perrett]

From what you're saying the remote service calls back to you're application? If thats the case, it's going to create a new session every time time i'm afraid, so in that case you're going to have to keep a reference to the session whatever you do: Lift's function mapping system maps functions to be executed later as references into the scoped map.

I'm not 100% sure what you are hoping to achieve, or what specifically is the problem with passing the JSESSIONID? 

Cheers, Tim

[Sergey Trofimov]

Remote service just redirect browser to callback URL.
Everything happens in the browser.

There is no problem with passing JSESSIONID.
I'm just curious if alternative solution is possible because I know that Lift is able to pass objects using request variables.

Thank you.

[Ján Raska]

On Apr 13, 2011, at 20:23 , Sergey Trofimov wrote:

> Remote service just redirect browser to callback URL.
> Everything happens in the browser.

A while ago, before I started to use Lift I was implementing a similar system, that communicated with a third party service by redirection (credit card payments done through bank's cardpay system)

At that time, I did it by persisting an object and passing an ID, that was also included in a callback request and by that ID I was able to pick up a correct object.

However, I'm wondering, if it's all done in a browser by redirection, then when you are redirected back, you should still have the same session if you didn't quit your browser. Thus SessionVar should serve you well even without passing a jsessionid to a remote service. But maybe I'm missing something...

>
> There is no problem with passing JSESSIONID.
> I'm just curious if alternative solution is possible because I know that Lift is able to pass objects using request variables.

Personaly I prefer to pass around as little as possible and have as much data kept on a server as I can. Because you never know what may happen with it while travelling around. Thus I'd use such solution (if it exists) only if I had no other choice. But that's just me...

[Sergey Trofimov]

Hello Ján.

At that time, I did it by persisting an object and passing an ID, that was also included in a callback request and by that ID I was able to pick up a correct object.

How did you get object ID?
How did you pick up object back?
 

 

However, I'm wondering, if it's all done in a browser by redirection, then when you are redirected back, you should still have the same session if you didn't quit your browser. Thus SessionVar should serve you well even without passing a jsessionid to a remote service. But maybe I'm missing something...

Yes, I also were wondered (having PHP experience) that session is not reliable, at least in development mode under SBT′s jetty-run.
I've wrote about this in the group.

 

Personaly I prefer to pass around as little as possible and have as much data kept on a server as I can. Because you never know what may happen with it while travelling around. Thus I'd use such solution (if it exists) only if I had no other choice. But that's just me...

I expect that passing object ID′s is comparable with passing session id.
I did not mean to pass whole object around similar to RequestVar feature of the Lift.

--
Sergey

[Ján Raska]

Hi Sergey,

On Apr 14, 2011, at 6:51 , Sergey Trofimov wrote:

Hello Ján.

At that time, I did it by persisting an object and passing an ID, that was also included in a callback request and by that ID I was able to pick up a correct object.

How did you get object ID?
How did you pick up object back?

In one scenario I used database. I had to store it to database after coming back anyways, so I did it before doing a redirect and used primary key as my ID. After coming back I just searched in DB by the PK.

In other scenario I had a hashmap in a singleton object, I stored object into a map using random generated UUID as a key, and passed that one. After coming back I used UUID to get a value from map.

 

 

However, I'm wondering, if it's all done in a browser by redirection, then when you are redirected back, you should still have the same session if you didn't quit your browser. Thus SessionVar should serve you well even without passing a jsessionid to a remote service. But maybe I'm missing something...

Yes, I also were wondered (having PHP experience) that session is not reliable, at least in development mode under SBT′s jetty-run.
I've wrote about this in the group.

As far as I know, they are reliable, one just need to understand how and when they're created and how and when they're destroyed (eg. ProtoUser login/logout destroys a session and creates a new one, so after user logs in or logs out, SessionVars will be empty). But unfortunatelly, I don't completely understand session lifecycle either.

 

Personaly I prefer to pass around as little as possible and have as much data kept on a server as I can. Because you never know what may happen with it while travelling around. Thus I'd use such solution (if it exists) only if I had no other choice. But that's just me...

I expect that passing object ID′s is comparable with passing session id.
I did not mean to pass whole object around similar to RequestVar feature of the Lift.

I misunderstood you then. I thought you're going to serialize and pass whole object :). However, if you need to access just one object after coming back, passing object's ID is imho safer then session id, as that'll give you access to all other session objects. But some people say I'm just scared too much :)

--
Sergey

[David Pollak]

Personally, I'd do this with RequestVars rather than with SessionVars because that gives you scope over the variables (they're good for the scope of a single request rather than for the entire session).

So, if you've got a couple of RequestVars, you can do the following:

object rv1 extends RequestVar...
object rv2 extends RequestVar...

def snapshot(): () => Unit = {
  val v1 = rv1.get
  val v2 = rv2.get
  () => {rv1.set(v1); rv2.set(v2)}
}

def buildCallbackURL(baseURL: String): String = S.fmapFunc(snapshot())(key => Helpers.appendFuncToURL(baseURL, key +"=_"))

The snapshot method creates a function that will restore the RequestVars to the state that they had when it was called.  The buildCallbackURL method takes a base URL (built using whatever mechanism you choose) and appends the restore function to it.  When that URL is hit on the server, the RequestVars will be restored and away you go.

Hope this helps.

Thanks,

David
 

Thank you.

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net

Simply Lift http://simply.liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Sergey Trofimov]

Thank you, David.

This is exact information which I was searching for.

[Naftoli Gugenheim]

On Thu, Apr 14, 2011 at 9:28 AM, David Pollak <feeder.of...@gmail.com> wrote:

On Wed, Apr 13, 2011 at 11:23 AM, Sergey Trofimov <sergey....@gmail.com> wrote:

Remote service just redirect browser to callback URL.
Everything happens in the browser.

There is no problem with passing JSESSIONID.
I'm just curious if alternative solution is possible because I know that Lift is able to pass objects using request variables.

Personally, I'd do this with RequestVars rather than with SessionVars because that gives you scope over the variables (they're good for the scope of a single request rather than for the entire session).

So, if you've got a couple of RequestVars, you can do the following:

object rv1 extends RequestVar...
object rv2 extends RequestVar...

def snapshot(): () => Unit = {
  val v1 = rv1.get
  val v2 = rv2.get
  () => {rv1.set(v1); rv2.set(v2)}
}

def buildCallbackURL(baseURL: String): String = S.fmapFunc(snapshot())(key => Helpers.appendFuncToURL(baseURL, key +"=_"))

The snapshot method creates a function that will restore the RequestVars to the state that they had when it was called.  The buildCallbackURL method takes a base URL (built using whatever mechanism you choose) and appends the restore function to it.  When that URL is hit on the server, the RequestVars will be restored and away you go.

Neat code! Maybe it would be useful to have a generalization in the library?

1. def snapshot(rvs: RequestVar*): ()=>Unit

2. def urlWithState(baseUrl: String, state: ()=>Unit)

[Ján Raska]

Nice one :). Can I suggest to have this one placed on Lift's wiki? There might be more people in the future looking for same answer

[David Pollak]

On Thu, Apr 14, 2011 at 12:16 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:

On Thu, Apr 14, 2011 at 9:28 AM, David Pollak <feeder.of...@gmail.com> wrote:

On Wed, Apr 13, 2011 at 11:23 AM, Sergey Trofimov <sergey....@gmail.com> wrote:

Remote service just redirect browser to callback URL.
Everything happens in the browser.

There is no problem with passing JSESSIONID.
I'm just curious if alternative solution is possible because I know that Lift is able to pass objects using request variables.

Personally, I'd do this with RequestVars rather than with SessionVars because that gives you scope over the variables (they're good for the scope of a single request rather than for the entire session).

So, if you've got a couple of RequestVars, you can do the following:

object rv1 extends RequestVar...
object rv2 extends RequestVar...

def snapshot(): () => Unit = {
  val v1 = rv1.get
  val v2 = rv2.get
  () => {rv1.set(v1); rv2.set(v2)}
}

def buildCallbackURL(baseURL: String): String = S.fmapFunc(snapshot())(key => Helpers.appendFuncToURL(baseURL, key +"=_"))

The snapshot method creates a function that will restore the RequestVars to the state that they had when it was called.  The buildCallbackURL method takes a base URL (built using whatever mechanism you choose) and appends the restore function to it.  When that URL is hit on the server, the RequestVars will be restored and away you go.

Neat code! Maybe it would be useful to have a generalization in the library?

1. def snapshot(rvs: RequestVar*): ()=>Unit

2. def urlWithState(baseUrl: String, state: ()=>Unit)

Please open a ticket and assign it to me for 2.4 and I'll add some stuff.
 

[Diego Medina]

On Thu, Apr 14, 2011 at 9:28 AM, David Pollak
<feeder.of...@gmail.com> wrote:
>
>

> On Wed, Apr 13, 2011 at 11:23 AM, Sergey Trofimov
> <sergey....@gmail.com> wrote:
>>
>> Remote service just redirect browser to callback URL.
>> Everything happens in the browser.
>>
>> There is no problem with passing JSESSIONID.
>> I'm just curious if alternative solution is possible because I know that
>> Lift is able to pass objects using request variables.
>
> Personally, I'd do this with RequestVars rather than with SessionVars
> because that gives you scope over the variables (they're good for the scope
> of a single request rather than for the entire session).
>
> So, if you've got a couple of RequestVars, you can do the following:
>
> object rv1 extends RequestVar...
> object rv2 extends RequestVar...
>
> def snapshot(): () => Unit = {
>   val v1 = rv1.get
>   val v2 = rv2.get
>   () => {rv1.set(v1); rv2.set(v2)}
> }
>
> def buildCallbackURL(baseURL: String): String = S.fmapFunc(snapshot())(key
> => Helpers.appendFuncToURL(baseURL, key +"=_"))
>

This is one of those code snippets I see and want to find a way to use
them asap :) There is still so much to learn about Lift ...

Diego

#callback

--
Diego Medina
Web Developer
http://www.fmpwizard.com

[Sergey Trofimov]

Well, the ticket is created.
http://www.assembla.com/spaces/liftweb/tickets/978-add-helpers-to-snapshot-and-pass-objects-in-request-parameters

[Sergey Trofimov]

Hello, Ján.

You can even place this on the wiki yourselves ;-)