[Seaside] Seaside sessions and ajax

[Sebastian Sastre]

> It doesn't work in the first browser I tried :-(
> 

So it must be Opera. Quoting Yahoo: 
"Opera is not supported at this time. This is due to the fact that Opera
does not update the location.hash property when using the back/forward
buttons. We expect this regression to be corrected in a future version of
the Opera web browser."
I was reading about statistics and seems that Opera never reached 2% of a
market share that is not a half strategic Safari is. 

> > I know Seaside does not do that by default by I see no exit 
> for that. 
> > Things seems to be scaling there (I value opinions here). I mean to 
> > the need of having a DOM element wich is an homologue of 
> the Seaside component.
> 
> The question is, if Seaside components are really something 
> that you want? I know some AJAX heavy applications that just 
> have one root component, the rest is done trough renderable 
> objects. Maybe it would make sense instead of having a 
> persistent component tree to have a persistent DOM tree? A 
> tree that can be backtracked and that knows what gets 
> modified, so that only changed parts are transmitted?
> 
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?

> > I'm doing it and I'm very satisfied by it. To achieve that 
> I'm using a 
> > component hierarchy that wraps in a div whatever it has to 
> render inside.
> > When I need to update any of those I know I can by making 
> an updater 
> > to work with it's id. Beside that server-side convenience I use to 
> > take advantage of that id to perform user agent things 
> among elements.
> 
> Generally this restricts the user too much in the way the 
> XHTML is generated.
> 
I don't get you on this. What kind of restrictions you mean? By user you
mean the user of Seaside, or final user?
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.

> > Beside that I think we could possibly need to identify updaters, 
> > evaluators and requestors to relate them to a defined continuation. 
> > That way we make YUI to use that unique callbak:
> >
> > YAHOO.util.History.register ( componentId , initialState , 
> > onStateChange , obj , override )
> 
> I don't really see the point of using continuations (yet). Of 
> course continuations are a cool solution to many problems, 
> maybe not this one. So I would start with the problem for now ;-)
> 
> Cheers,
> Lukas
> 
Actual Seaside components are solving the problem of backtraking actions
only for and coupled to full renders (maybe this is why you asked about if
seaside components are really what I want for this?). 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).
If those components have to exists in a different hierarchy other than
WAComponent let's be it.

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).

We can make the callback at onStateChange that the history manager calls to
execute an updater over the same dom element that matches the seaside
component with the seaside callback that will render the previous state.

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

	Cheers,

Sebastian