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. What would a re-usable Aida Login and LoginApp look like? Could it be both called and embedded as in Seaside? |
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. 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 -- Nicolas Petton http://nico.aidaweb.si ___ ooooooo OOOOOOOOO |Smalltalk| OOOOOOOOO ooooooo \ / [|] -------------------------------- Ma clé PGP est disponible ici : http://nico.aidaweb.si/pgp-key.html _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
In reply to this post by Frank Young
Hi Frank, welcome to the list!
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. > 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. 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. What about back button? Back button will lead you out of that page full of stackable windows, but forward button will let you back to exactly the same state as before. If leaving this page is not desirable, we will disallow it with additional popup window. So, that way, we will preserve all Aida strengths while close the last gap to the competition! Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
In reply to this post by Nicolas Petton
Hi Nico, Thanks for providing that CounterComponent example of reusable components in Aida. I think that illustrates what I was referring to as an embeddable component, which Seaside embeds into a current page using: self render: counterComponent To make an Aida component reusable as an embeddable component, it needs to subclass from WebComponent or WebElement, as opposed to WebApplication, while in Seaside all components subclass from WAComponent. Furthermore, a model named YYYY would have a corresponding WebApplication named YYYYApp if an YYYY object were url-linked e addLinkTo: yyyy text: 'some text' so that if the yyyy instance is selected, Aida would delegate the view to YYYYApp. To reference the model instance yyyy from YYYYApp would require calling self observee from YYYYApp (Are there any other uses of WebApplication in Aida besides being used as a delegated view of a model?). In embeddable components, however, all of this delegation goes away. The CounterComponent does not use the observer pattern to obtain a reference to the model. The model has to be an instVar of CounterComponent: WebComponent subclass: #CounterComponent instanceVariableNames: 'counter' classVariableNames: '' poolDictionaries: '' category: 'CounterDemo' CounterComponent>>initialize counter := Counter new So I guess one distinction between url-linked components and embeddable components in Aida is that url-linked components use delegation to reference the model, while embeddable components use composition, whereas in Seaside all WAComponents use composition. You also mentioned: Is it necessary for components to use Ajax, rather than to simply refresh or update the page (I'm still somewhat uneasy about Ajax, and usually prefer to design sites without it if possible)? Frank |
In reply to this post by Janko Mivšek
Thanks Janko, much obliged. 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 http://www.nabble.com/Re%3A-Aida-%22Flow-Control%22-p17534621.html 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. 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 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. 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 |
Free forum by Nabble | Edit this page |