[Seaside] Seaside vs. Aida
itsme213
itsme213 at hotmail.com
Sun Mar 30 22:14:56 UTC 2008
"Janko Mivsek" <janko.mivsek at eranova.si> wrote
> ...
Thanks for sharing your insights.
> In Aida we have a WebElement which start covering primitive elements
> like images, links or text, and ends up to the whole web page.
> WebElement can namely be a composite of sub elements down to primitive
> ones. We have therefore a consistent component model from a web page
> down to primitive elements.
I think this has some real advantages (like Michael Lucas-Smith's earlier
post), though I am not sure of the trade-offs. Lukas explained earlier that
Seaside uses explicit Components and their #children to do several things...
> 1. parse the initial request (#initialRequest:)
> 2. change the current URL (#updateUrl:)
> 3. register objects for backtracking (#updateStates:)
> 4. render something to the XHTML head (#updateRoot:)
> 5. render something to the XHTML body (#renderContentOn:)
> 6. process callbacks (#processCallbackStream:)
Does Aida handle these elsewhere? How would a "component" hook into or
customize any of 1-6?
Also, does Aida have anything like (or have you any plan for something like)
Scriptaculous, to allow talking to client-side Javascript from pure
Smalltalk?
> In Seaside you start painting a component, using a hierarchy of blocks.
> In Aida you continue building with smaller and smaller WebElements.
Yes, render html vs. construct DOM tree.
Perhaps the "hierarchy of blocks" part can be seen as just an API style, and
could also be used as an API to construct a DOM tree behind the scenes,
where Seaside's #div, #anchor, #table, etc. would construct DOM nodes, and
#with: would start constructing the sub-tree ?
- Sophie
More information about the seaside
mailing list