[Seaside] Seaside sessions and ajax

[Lukas Renggli]

> So it must be Opera.

It is Safari, another unsupported browser.

I don't like hacks that are likely to break with the next service pack.

> OK, let's say all is done like that, I mean one root seaside compoenent and
> the rest just another kind of rendereable objects, what have you gained by
> doing that?

Just an idea. It might not work for you.

> I don't get you on this. What kind of restrictions you mean? By user you
> mean the user of Seaside, or final user?

I don't want a DIV around all my components.

  http://www.whatstyle.net/articles/22/less_div_more_html
  http://www.motive.co.nz/glossary/div.php

> The fact is that didn't stop me yet of doing anything. Besides behavior, if
> you're valuing the elegance of the html I would agree. The html would seem
> heavy but todays it can travel deflated by apache. Besides The structure of
> what I have rendered on the user agent is kind of homogeneus in nature even
> in a high degree of composition. I know that it should be the designer's
> problem but I think I've also have solved a priori most of the positioning
> problems with this. By having a little painful experience on layouting
> things in html you may know how valuable this could be.

I don't see how these DIVs could be valuable for a designer, as they
are probably auto generated. What worried me initially was that I had
the impression that you wanted to put a DIV around every component.

> So I say we can scale
> that to make a family of components that are also AJAXianly backtrackeable.
> Those components have the trade off of having to be identifiable in the DOM
> and capable of setting it's innerHTML (that's why I've choosed to wrapp with
> div containers).

That makes sense.

> If those components have to exists in a different hierarchy other than
> WAComponent let's be it.

Sure that's a detail. I don't see any problems in starting with a
subclass of WAComonent, I just feel that maybe later on you might want
to choose a different superclass. WAComponent provides a lot of
functionality that might not be too useful in your context.

> I thought in continuations because how Seaside works. Suposing AJAX did not
> exists, Seaside maps one unique url per reandereable action. What I was
> thinking is that we can map those rendereable actions also to AJAX style of
> render elements: updaters. If the problem to solve is backtrack rendereable
> actions, no matter if they are full or partial, I think Seaside is the
> winner because of continuations (I say this because one can go back and
> forward in different "branches" of actions and as far as I know only
> continuations handle that).

So far, I don't see any use of continuations. Seaside only uses
continuations to wait in the middle of a method for the next request,
e.g. with #call: and #answer:. The state backtracking has nothing to
do with continuations (with the exception of the method-temps that are
part of a suspended method).

> I'm still thinking loud here so please feel free to feedback,

Interesting discussion.

Cheers,
Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch