[aida] Re usable Components in Seaside & Aida

Frank Young franklin1 at runbox.com
Sat Jan 31 01:30:45 CET 2009

Janko Mivsek wrote:
> Hi Frank, welcome to the list!

Thanks Janko, much obliged.

Janko Mivsek wrote:
> Frank Young pravi:
> ...
>> In Seaside, one can call this LoginComponent
>> 		self call: LoginComponent new
>> to have a login page pop up, or one can render an embedded LoginComponent
>> within the current page:
>> 		html render: loginComponent
>> similar to how a Java applet can function either as an applet or as a
>> Java
>> application (if called from an AWT Frame).
>> I think this is one of the strong points of Seaside in permitting
>> WAComponents to be used in different contexts, so that programmers can
>> easily develop a library of reusable components.
> Yes it is, by for what cost? IMO inacceptable high one, so in Aida we
> are thinking in different direction. See below.

Though I find it a very elegant and orthogonal way of programming, you may
be right that it increases complexity in other areas of Seaside.  As you and
Nico Petton has pointed out in a different thread


Janko Mivsek wrote:
> But one big difference comparing to Seaside is that we have only one 
> form per page. All form elements are recursively registered into that 
> sole form just before page got rendered into HTML.


Nicolas Petton wrote:
> For the programmer, the difference is that you don't have to deal with 
> forms when you build your pages, while with Seaside you do. On the other 
> hand, it's sometimes annoying to have this form on top of everything in 
> your html page when you write CSS. Nothing very important, but your 
> final css may be a bit different, because of this form. 

In general, I find Aida html rendering much more readable than Seaside's,
which appears more verbose and overly fine-grained.  Having a single
implicit form in each Aida page greatly simplifies html programming.

Janko Mivsek wrote:
>> From what I have seen of Aida, it uses a state machine-like process to
>> transition and navigate among different web pages rather than Seaside's
>> subroutine-like flow control.  I wonder, though, how Aida supports
>> reusable
>> components given this distinction.
>> What would a re-usable Aida Login and LoginApp look like?  Could it be
>> both
>> called and embedded as in Seaside?
> Nico already shown well how Aida reusable components look like, while
> for traditional login you can see the WebAdminApp>>viewLogin.
> Yes it is state machine-like approach, which is good and has proven to
> scale well in terms in complexity, but can become quite complicated for
> simple things like confirmation dialogs. Here Seaside is definitely
> better, but as said, for too big cost.

There are however other aspects of navigation in Aida, that I am uncertain
about.  In that same earlier thread, you mentioned how you usually provide a
parent in child domain models so that each child knows its parent.  That way
one can navigate from parent pages to child pages and back to parent pages.


Janko Mivsek wrote:
> I think here we are talking more about navigation than a workflow. The 
> navigation down to some domain hierarchy and back. And here is the 
> problem, how to climb the hierarchy back to the top. 
> I actually have parent relationships in my domain model so that every 
> child knows its parent too. That way you can achieve a complete 
> navigation from domain mode alone, without some special tricks like 
> remembering where you come from etc. That's why my web apps are full of 
> navigation support like hierarchical links, left/right buttons to 
> navigate horizontally, etc. See this page for example: 
>         http://geomer.eranova.si:8000/merilo/korektor/900/89008074.html

Unfortunately, I think placing a parent pointer in each child exposes
presentation-level semantics into the model.  A child that would not usually
need to know its parent is being forced to carry a parent pointer for the
purpose of web-page navigation.  There ought to be a different way of
solving this than having to insert extra information into the model.

Janko Mivsek wrote:
> What we will do is an introduction of stackable modal windows inside one
> page.
> Like yes/no confirmation dialogs. As those dialogs you can see on
> Facebook and similar sites recently. These will be Ajax made windows,
> with complete form support. They will be instances of WebComponent.
> So, kind a hybrid approach: usual Aida one up to the page, then
> tree-like control flow with stackable modal windows inside that single
> page.

This does sound like a very nice solution for Aida.  It provides modal 
functionality while preserving the ease and simplicity of Aida programming. 
Would it also solve the earlier navigation problem of having a child point
back to its parent?


View this message in context: http://www.nabble.com/Reusable-Components-in-Seaside---Aida-tp21743322p21758317.html
Sent from the AIDA/Web mailing list archive at Nabble.com.

More information about the Aida mailing list