[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