[Seaside] Questions about double (or more) request

[Mariano Martinez Peck]

Excellent. Now I get it. Thank you so much for your answers.

Best,

Mariano

On Thu, Aug 6, 2009 at 5:22 PM, Philippe Marschall <
philippe.marschall at gmail.com> wrote:

> 2009/8/6 Mariano Martinez Peck <marianopeck at gmail.com>:
> >
> >
> > On Thu, Aug 6, 2009 at 4:16 AM, Philippe Marschall
> > <philippe.marschall at gmail.com> wrote:
> >>
> >> 2009/8/5 Mariano Martinez Peck <marianopeck at gmail.com>:
> >> > Hi! I am trying to understand how seaside handle double or more,
> >> > request. I
> >> > started with the simpler example: WACounter, which has:
> >> >
> >> > renderContentOn: html
> >> >     Transcript show: 'renderContentOn'; cr.
> >> >     html heading: count.
> >> >     html anchor
> >> >         callback: [ self increase ];
> >> >         with: '++'.
> >> >     html space.
> >> >     html anchor
> >> >         callback: [ self decrease ];
> >> >         with: '--'
> >> >
> >> >
> >> > increase
> >> >     Transcript show: 'increase'; cr.
> >> >     count := count + 1.
> >> >     (Delay forSeconds: 3) wait.
> >> >
> >> >
> >> > Now, suppose the counter is in 0. I click one time on '++' and wait
> and
> >> > I
> >> > see in the transcipt:
> >> >
> >> > increase
> >> > renderContentOn
> >> >
> >> > Ok, perfect. New session, 0 again. Now I click on '++' but before it
> >> > finish,
> >> > I click 3 times more (very quickly). I can see this in the transcipt:
> >> >
> >> > increase
> >> > increase
> >> > increase
> >> > increase
> >> > renderContentOn
> >> >
> >> > So, as I can see:
> >> >
> >> > 1) the callback (self increase in this case) is called for every
> click.
> >> > 2) the renderContentOn isn't call until all of the self increase of
> that
> >> > session finish.
> >> > 3) when renderContentOn  is called, the webpage shows the number 1
> >> > (which is
> >> > correct instead of 4).
> >> >
> >> > Now the questions are:
> >> >
> >> > a) how does seaside can do that? every request has its own variables?
> I
> >> > think this has to be with continuations but I want to be sure.
> >>
> >> I order of you observations:
> >> 1) You (your browser) makes three callback requests and discards the
> >> redirect to render for the first two
> >
> > Ok, but which is the "condition" to be discarded? if the callback request
> is
> > finished but there are others callbacks request then it is discarded?
>
> Seaside doesn't discard anything, the browser has to. Here's a rough
> sketch of what happens:
> - You initiate a content exchange for the "callbacks page".
> - The browser sends a request.
> - The Seaside callback machinery kicks in.
> - Before Seaside can send a response you initiate three more requests
> resulting in three more requests.
>
> Seaside doesn't really have a problem with this, it will process these
> requests one after another, meaning "executing" the same "callback
> page" several times and send the redirect response to the render page
> for each one. However the browser has, he has just one pane where he
> can render the resonse. So he'll have to discard all but one of the
> responses. The least bad thing is to discard all but the last one.
>
> >>
> >> 2) There is a lock that allows only one request per session at a time,
> >> otherwise your components would have to be thread safe
> >> 3) state backtracking, before every request the state of the counter
> >> is reverted to 0
> >
> > that's because there was the method states ?
>
> Yes
>
> >>
> >> > b) which of all of the self increase is the one that is finally
> >> > rendered?
> >> > the first one?
> >>
> >> That should be the last one. The browser should discard processing the
> >> previous requests. Disable backtracking to be sure.
> >
> > what do you mean with Disable backtracking ? remove the method states
> from
> > the component?
>
> Yes
>
> Cheers
> Philippe
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090806/a248760c/attachment-0001.htm