[Seaside] Questions about double (or more) request

[Mariano Martinez Peck]

Thanks to all. Now I get it. But...I still wonder how can I manage double
request.

c) how can I handle the famous double commit? suppose now self increase does
something in a relational database (like persisting an order or something
like that) and I don't want it to get persisted twice or I don't want an
error because of duplicated PK

thanks for the help!

mariano

On Wed, Aug 5, 2009 at 6:11 PM, Diogenes Alberto Moreira <
diogenes.moreira at gmail.com> wrote:

> The point is that, for every click you do, seaside run a continuation
> it is identified by the  _s _f and  a number.
>
> At this point when you assign a block to call back the block is
> leads to the context, where count is a value x, eg 20
>
> if you run  70 times the same continuation, count value will be the same 21
>  (20 +1).
>
> because that,  Transcript show increase, increase, increase,
> renderContentOn and the count value is the same 21.
>
> because that, fixtemp is very important in squeak, and Pharo have better
> behavior.
>
> wich click is running all... but al run the same block
>
> regard (sorry for my google english).
>
> El 05/08/2009, a las 15:54, Diogenes Alberto Moreira escribió:
>
>
>  Bueno te lo contesto en castellano y despues trato de traducirlo. en otro
>> mail (sorry for english speakers, my English is horrible)
>>
>> El punto es este, por cada click que haces se ejecuta un continuation que
>> esta identificado por el _s para la session _k para el componete un numero
>> de &.
>> en punto que cuando vos le asignas un bloque al call back el bloque se
>> lleva el contexto, donde count tiene un valor x, por ejemplo 20
>>
>> por mas que ejecutes 70 veces, en el contexto del bloque count vale 20  e
>> incease ejecuta count := 20 + 1.
>>
>> por eso en el transcript, te aperece increase, incease, rendercontentOn y
>> el valor que toma count es simpre 21. (para nuestro ejemplo). y por eso lo
>> importante del fixtemp en squeak y la mejora que significo Pharo.
>>
>> cual se ejecuta,,, todos.... pero todos hacen lo mismo...
>>
>> Espero ser claro....
>>
>> PD: mariano ponele onda y traducilo.
>>
>> Saludos
>>
>> El 05/08/2009, a las 15:40, Mariano Martinez Peck escribió:
>>
>>  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.
>>> b) which of all of the self increase is the one that is finally rendered?
>>> the first one?
>>> c) how can I handle the famous double commit? suppose now self increase
>>> does something in a relational database (like persisting an order or
>>> something like that) and I don't want it to get persisted twice or I don't
>>> want an error because of duplicated PK.
>>>
>>> Thanks for the help. I just want to understand how this is handle!
>>>
>>> best,
>>>
>>> Mariano
>>> _______________________________________________
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>>
> _______________________________________________
> 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/20090805/d77d797e/attachment-0001.htm