|
List Info
Thread: session question
|
|
| session question |
  United States |
2007-04-08 14:56:55 |
|
| Another newbie question I just didn't seem to get a straight answer from the docs.
I have created a signin modaldialog (thanks to everyone who replied to my classroot issue). The point of the dialog is to maintain the user has signed in through the life of the app of course. So, from Laszlo and the front-end this is very easy, but I am not sure I get how the backend session is managed.
Since I am a Struts developer, I created a Struts back-end and the signin dataset, as well as every other, will go to a "dot-do". This works fine, but how does Laszlo accept the session information from the J2EE server (or just Tomcat) and how does Laszlo in turn send the session information back with each request to the server.
Or am I missing my metaphors and the client should be robust enough to handle a stateless back-end? I read the docs and it seems overly complex to be managing the cookies by hand which is where the jsessionid lives.
Thanks, Steve Steven Melzer smmelzer  gmail.com" >smmelzer gmail.com
|
| Re: session question |
  United States |
2007-04-08 16:53:03 |
|
| To outline one approach
If you are using 100% server side sessions (that is, some storage keyed to a session id) then the flash player will send cookies with every request just like a browser. This is sufficient for my own purposes, and it seems like dumping a state dataset back to the server a determined points is enough to maintain state, all together bypassing any other cookie on the server. In my own (perhaps incomplete) take on the subject, cookies with the exception of id strings are a hack to deal with the fact that an html page is stateless, while laszlo applications have places to put state very nicely via datasets.
Best, James.
On Apr 8, 2007, at 3:56 PM, Steven Melzer wrote: Another newbie question I just didn't seem to get a straight answer from the docs.
I have created a signin modaldialog (thanks to everyone who replied to my classroot issue). The point of the dialog is to maintain the user has signed in through the life of the app of course. So, from Laszlo and the front-end this is very easy, but I am not sure I get how the backend session is managed.
Since I am a Struts developer, I created a Struts back-end and the signin dataset, as well as every other, will go to a "dot-do". This works fine, but how does Laszlo accept the session information from the J2EE server (or just Tomcat) and how does Laszlo in turn send the session information back with each request to the server.
Or am I missing my metaphors and the client should be robust enough to handle a stateless back-end? I read the docs and it seems overly complex to be managing the cookies by hand which is where the jsessionid lives.
Thanks, Steve Steven Melzer smmelzer  gmail.com" >smmelzer gmail.com
|
| Re: session question |
  United States |
2007-04-08 20:32:37 |
|
| James,
That is a good point about Laszlo being able to maintain its own state in datasets I guess I need a paradigm shift class  But can you give me a bit more detail on your best practices. Specifically, I would want to be able to store a userID in a dataset that I can send server side to perform transactions. This is the same thing basically as storing state in the server (and allows me to use a much smaller server). However, I need to be able to pass this userID, or any other "general" information, with a dataset of other data.
To be more general, how do I combine data from multiple datasets to pass as the query parameters to a request. Is it just a matter of pulling data from one dataset and popping it into the "request" dataset?
Is there a security risk here if I am using DHTML as a fallback option if Flash is unavailable?
All, Are there are large-scale enterprise Laszlo sites which support thousands of users?
Thanks, Steve
On Apr 8, 2007, at 5:53 PM, jamesr wrote: To outline one approach
If you are using 100% server side sessions (that is, some storage keyed to a session id) then the flash player will send cookies with every request just like a browser. This is sufficient for my own purposes, and it seems like dumping a state dataset back to the server a determined points is enough to maintain state, all together bypassing any other cookie on the server. In my own (perhaps incomplete) take on the subject, cookies with the exception of id strings are a hack to deal with the fact that an html page is stateless, while laszlo applications have places to put state very nicely via datasets.
Best, James.
On Apr 8, 2007, at 3:56 PM, Steven Melzer wrote: Another newbie question I just didn't seem to get a straight answer from the docs.
I have created a signin modaldialog (thanks to everyone who replied to my classroot issue). The point of the dialog is to maintain the user has signed in through the life of the app of course. So, from Laszlo and the front-end this is very easy, but I am not sure I get how the backend session is managed.
Since I am a Struts developer, I created a Struts back-end and the signin dataset, as well as every other, will go to a "dot-do". This works fine, but how does Laszlo accept the session information from the J2EE server (or just Tomcat) and how does Laszlo in turn send the session information back with each request to the server.
Or am I missing my metaphors and the client should be robust enough to handle a stateless back-end? I read the docs and it seems overly complex to be managing the cookies by hand which is where the jsessionid lives.
Thanks, Steve Steven Melzer smmelzer  gmail.com" >smmelzer gmail.com
Steven Melzer smmelzer  gmail.com" >smmelzer gmail.com
|
| Re: session question |

|
2007-04-08 23:27:22 |
Hi,
Just to be clear about the userID - unless i'm misreading
you, the
idea is that you never need explictly send it - it is this
ID (usually
generated via SHA or somesuch at the start of the session)
that will
be automatically sent - via normal cookie behaviour -
everytime a
request is made: Send "state" (a dataset) by
assigning a query
variable (in a POST!) to the datasets serialize() method and
store it
in your database for regurgitation on the next visit aka
next login.
What is important from all that is really that the serialize
method,
when assigned to a variable to be sent in a request to the
server, can
contains the contents of however many datasets you'd like.
Code
example:
<canvas>
<dataset name="stateset" src="http://getsome
.com/datasets"/>
<view onclick="var ds = canvas.datasets.stateset;
var obj = new
Object; obj.state = ds.serialize(); ds.setQueryString(obj);
ds.doRequest();">
<text text="Click me to send a dataset to the
server"/>
</view>
</canvas>
and if you decide to use another dataset as the serialze()
source,
then the results of this request (now filling the dataset
the
doRequest was called on) can contain, say, a string giving
the user a
confirmation message as well, which i like to do.
I'd expand if needed. Gotta love laszlo, generally datasets
rule, and
there are lots of neat things to be done. It's a good idea
to make
some naming scheme for them too, of course. I call normal
datasets
that request info at the beginning "remotesets"
and datasets that do
NOT request the first time that are just sending info (and
possibly
roundtripping status) "remotelinks".
It's late here, but i hope there be good for the writing of
this.
James
On 4/8/07, Steven Melzer <smmelzer gmail.com> wrote:
> James,
>
> That is a good point about Laszlo being able to
maintain its own state in
> datasets I guess I need a paradigm shift class But can
you give me a
> bit more detail on your best practices. Specifically,
I would want to be
> able to store a userID in a dataset that I can send
server side to perform
> transactions. This is the same thing basically as
storing state in the
> server (and allows me to use a much smaller server).
However, I need to be
> able to pass this userID, or any other
"general" information, with a dataset
> of other data.
>
> To be more general, how do I combine data from multiple
datasets to pass as
> the query parameters to a request. Is it just a matter
of pulling data from
> one dataset and popping it into the "request"
dataset?
>
> Is there a security risk here if I am using DHTML as a
fallback option if
> Flash is unavailable?
>
> All,
> Are there are large-scale enterprise Laszlo sites which
support thousands of
> users?
>
> Thanks,
> Steve
>
>
>
> On Apr 8, 2007, at 5:53 PM, jamesr wrote:
> To outline one approach
>
> If you are using 100% server side sessions (that is,
some storage keyed to
> a session id) then the flash player will send cookies
with every request
> just like a browser. This is sufficient for my own
purposes, and it seems
> like dumping a state dataset back to the server a
determined points is
> enough to maintain state, all together bypassing any
other cookie on the
> server. In my own (perhaps incomplete) take on the
subject, cookies with the
> exception of id strings are a hack to deal with the
fact that an html
> page is stateless, while laszlo applications have
places to put state very
> nicely via datasets.
>
> Best,
> James.
>
>
> On Apr 8, 2007, at 3:56 PM, Steven Melzer wrote:
> Another newbie question I just didn't seem to get a
straight answer from the
> docs.
>
> I have created a signin modaldialog (thanks to everyone
who replied to my
> classroot issue). The point of the dialog is to
maintain the user has
> signed in through the life of the app of course. So,
from Laszlo and the
> front-end this is very easy, but I am not sure I get
how the backend session
> is managed.
>
> Since I am a Struts developer, I created a Struts
back-end and the signin
> dataset, as well as every other, will go to a
"dot-do". This works fine,
> but how does Laszlo accept the session information from
the J2EE server (or
> just Tomcat) and how does Laszlo in turn send the
session information back
> with each request to the server.
>
> Or am I missing my metaphors and the client should be
robust enough to
> handle a stateless back-end? I read the docs and it
seems overly complex to
> be managing the cookies by hand which is where the
jsessionid lives.
>
> Thanks,
> Steve
>
>
> Steven Melzer
> smmelzer gmail.com
>
>
>
>
>
>
> Steven Melzer
> smmelzer gmail.com
>
>
>
>
|
|
[1-4]
|
|