[Seaside] Seaside vs. Aida

Janko Mivšek janko.mivsek at eranova.si
Mon Mar 31 15:23:33 UTC 2008

Hi Sophie,

itsme213 wrote:

> 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?

1-2: Url resolution: first, in Aida url always point to the domain 
object and not to a Component as in Seaside. Domain object then in MVC 
fashion delegates the request to its so called WebApplication (shorter: 
App) which is responsible for VC part of MVC. Domain object needs to 
therefore have a corresponding App class. Counter needs CounterApp. This 
App is then roughly the same as Seaside's root component.

3: Backtracking: Aida don't have backtracking. Why no, maybe later.

4-5: Rendering: is a two step in Aida: first building the object 
presentation of page, then serializing it into HTML. After an App 
receives a request (actually a #printWebPage call) it starts building a 
kind of object DOM tree of page. Then a #printHTMLPage is sent to render 
a page into HTML. This two step process has advantages like freedom of 
order how you build a page or "late binding" of page header info and 
also that you can render in something else instead of HTML. Main 
disadvantage is that it takes more time.

6. Actions: Aida don't have callbacks but are actions in MVC fashion 
strictly separated in separate methods, which are implemented in Apps. 
For instance for view #viewMain you can have an action in method 
#actionMain. Also form data posting is automatic directly to the domain 
objects. Usually you'll see such code in Aida:

	e addInputFieldAspect: #name for: self observee

Here we add an input field to edit a name of a domain object (named 
observee, in accordance to Observer pattern).

But we are thinking on introduction callback like server side validation 
of form input fields. Here the callbacks won't intermix too much the 
presentation code with action and business logic, which we'd like to 
keep separated, in the spirit of MVC paradigm.

> 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?

Yes, Prototype and Scriptaculous JS libraries are there by default and 
deeply integrated into Aida. Prototype is always loaded (needed for 
Ajax) while Scriptaculous is loaded on demand. Ajax support in Aida is 
one of its major strengths. For instance if you'd like to send input 
field immediately after something is entered, you would simply:

	aField onChangePost

...and field will be Ajax posted automatically. Such deep integration 
allows us now to ajaxify all new applications, because this brings so 
big benefit to users for so small cost.

>> 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 ?

Here I actually see the possibility to learn something from each other 
and I'm already thinking of introducing a simpler page building syntax 
with recent Seaside syntax as an example. Here Seasiders would also 
profit to extend component model to be more fine grained, with simpler 
and shorter methods as a first consequence.

Best regards

Janko Mivšek
Smalltalk Web Application Server

More information about the seaside mailing list