[Laszlo-user] session question
circlecycle at gmail.com
Sun Apr 8 21:27:22 PDT 2007
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
<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);
<text text="Click me to send a dataset to the server"/>
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.
On 4/8/07, Steven Melzer <smmelzer at gmail.com> wrote:
> 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?
> Are there are large-scale enterprise Laszlo sites which support thousands of
> 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.
> 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
> 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.
> Steven Melzer
> smmelzer at gmail.com
> Steven Melzer
> smmelzer at gmail.com
More information about the Laszlo-user