Reusable Components in Seaside & Aida

Nicolas Petton wrote

Le vendredi 30 janvier 2009 à 00:42 -0800, Frank Young a écrit :
> After learning a little about Seaside, I just tried out Aida/Web recently.  I
> found it simpler and easier to pick up than Seaside. In fact, Aida reminds
> me of Ruby on Rails in some ways, with its emphasis on naming and
> convention.  Methods are named viewXXXX and actionXXXX; models are named
> YYYY while their corresponding WebApplications are named YYYYApp.  Of
> course, Smalltalk provides a much faster and more productive development
> environment than any Ruby IDE.
>
> The most striking difference between Seaside and Aida that people have
> pointed out, of course, is control flow.  Seaside permits WAcomponents to be
> called, just like a subroutine, which facilitates reusability of that
> component.  Moreover, a WAComponent can also be rendered within a page as
> well, further enhancing its reusability.
>
> As an example, consider a WAComponent that acts as a login page, prompting a
> user for username and password:
>
> LoginComponent>>renderContentOn: html
> html form: [
> html text: 'Login: '.
>          html textInputOn: #username of: self; break.
>          html text: 'Password: '.
>          html passwordInputOn: #password of: self;break.
>          html submitButtonWithAction: [
> self authenticate] text: 'Login']]
>
> 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.
>
> 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.

We have several examples of resuable components in Aida. See WebGrid
class for example. I also a counter example for Aida:
http://nico.bioskop.fr/blog/a-multi-counter-with-aida/web.html

and the demo: http://nico.bioskop.fr/multicounter.html

As you can see, components in Aida heavily use Ajax, but as it is deeply
integrated in Aida, you shouldn't even notice it, except for some method
names!

to try a multicounter by yourself, load the class and methods from my
post, then in any application, add a view like this:

viewCounters
        | e |
        e := WebElement new.
        self counters do: [:each |
        e add: each].
        self pageFrameWith: e title: 'multi-counters'

counters
        ^counters ifNil: [
                counters := {CounterComponent new.
                        {CounterComponent.
                        {CounterComponent}]

cheers!

nico

As you can see, components in Aida heavily use Ajax, but as it is deeply
integrated in Aida, you shouldn't even notice it, except for some method
names!

Janko Mivsek wrote

Hi Frank, welcome to the list!

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.

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.

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.

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

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.