[Seaside] Seaside sessions and ajax
renggli at gmail.com
Thu Dec 6 06:43:51 UTC 2007
> Their example seems amazing:
It doesn't work in the first browser I tried :-(
> 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?
> 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.
> 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 ;-)
More information about the seaside