[Seaside] Seaside vs. Aida
janko.mivsek at eranova.si
Mon Mar 31 15:23:33 UTC 2008
> 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)
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:
...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.
Smalltalk Web Application Server
More information about the seaside