[Seaside] Re: How to mark not-cacheable?

[Esteban A. Maringolo]

On Jan 16, 2008 10:28 AM, Lukas Renggli <renggli at gmail.com> wrote:
> > But, and here comes the problem, if you go back the list will show
> > both elements, if you attempt to remove the already removed element,
> > you'll get a walkback (in this case reporting an NotFoundError).
>
> WATransactionExample>>renderContentOn: html
>        html unorderedList
>                list: collection;
>                callback: [:value | collection remove: value ifAbsent: []]
>
> Works perfectly ;-)

Cheater! :-)

> > Another option would be to associate the callback with a render pass,
> > or something similar.
> This has always been done like this.

Yeap, you're right.

> > I've read that tweaking the WALRUCache this could be achieved,
> > however, no one said how :-).
> I think the cleanest solution would be to make it an option for a
> callback to only trigger once. Should be fairly simple to do so.

Great, how much simple?

> There are two questions remaining:
 > - What happens if you try to trigger such a callback the second time?
> Do you specify another callback that should be triggered instead? Do
> you display an error message? Do you regenerate the current page? Do
> you redirect to the latest page?

The latest would be the safer option.
Another would be to handle this in the same way as #isolate: does.

> - Why does a [fundamental|unnecessary]? feature request comes after 7
> years of application development with Seaside? Is it because you have
> to take precaution anyway, just in case somebody else deleted the
> element from a different session? Is it because the remove
> functionality should be part of the model and handle this situation?

Well... actually it is handled at the domain level, raising an special
kind of exception, for the particular case (concurrency problems
mostly). But that kind of problems arise very rarely, and we use an
optimistic approach to concurrency in all of our traditional apps
(with peaks of 200 concurrent users). Leaving such cases to be handled
by an special "general" handler.
What I want is to avoid this kind of problems coming from the same
user, disabling the previous pages callbacks would fit now. If
collisions start to grow, then we will focus on solving them at
another level.

Thanks.

Best regards,

-- 
Esteban A. Maringolo
eMaringolo at gmail.com