[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

http://www.nabble.com/Re%3A-Aida-%22Flow-Control%22-p17522679.html


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

http://www.nabble.com/Re%3A-Aida-%22Flow-Control%22-p17534621.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.

http://www.nabble.com/Re%3A-Aida-%22Flow-Control%22-p17522179.html


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?

Frank


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