I was thinking of doing simple Ajax container myself, but after reading Frank's stuff, I saw broader possibilities. Let's continue in this thread, since gmail starting to slow down, trying to unfold 60+ messages ;)
Javascript is needed for ajax, period. If someone turns off Javascript in attempt to protect himself from viruses or popups, or turns off some important request headers like Referer (this one is needed in one of my projects), or does not want to upgrade to newer browser version, this is their choice. If they are afraid to drive a race car, let them ride a bicycle. Because Javascript is unseparable from "parallel requests" (at least in current XMLHTTPRequest form), the better possibilities can arise from using Javascript and DOM instead of generating page elements with custom tags and scriptlets. Struts-only or JSP-only solution is not good enough. The more portable is the better, so when I read Frank's proposal I thought, why those input controls are generated with custom tags? What if controls were created with Javascript? Custom tags would be generating setup parameters for these Javascript instead of generating input controls directly. The result is greater portability for the control library: basically, it would be a pure Javascript library. Appropriate (and portable) API must be created for controls' setup parameters. This API would describe Javascript methods as well as certain DOM structures and maybe whole page structure as well. Then, to port the library to other framework or language, only the code which creates parameters should be changed. Porting a pure Javascript library with Java-based API for input data may be easier, than porting Java-based tag library. Before reading Frank's proposal I was thinking about larger pieces of webpage, kind of like portlets. Frank suggests fine-grained approach, with event handlers for each button. What if these approaches were combined? We would have "controls" like in a desktop application, from button, to paragraph to table to div (basically all input controls plus block elements). Of course, div itself cannot accept input, so all these elements would have to have FORM on them. So, a page can be anything from monolitic page with ajax controls with individual event handlers, to portal-like page consisting of ajax blocks. Notice in Frank's article, that he loads data from a static URL, and generates data dynamically in the action class. This is how the larger ajax blocks should work: one _static_ URL for all. Well, some parameters which can be calculated in browser, can be supplied, like the RECT of the area where the larger block resides. I wrote couple of articles which touch this subject. The most recent one discusses the importance of stateful component with static URL, see http://today.java.net/pub/a/today/2005/03/29/webwizard2.htm?page=3 , please check "Web Flow Configuration" and "Controlling the browser" sections. The article was written before I started to seriously think about ajax, though. Check out this demo too, this one is not transformed to ajax yet, but this is very easy, since the whole thing is self-contained and is loaded from the same single URL: http://www.superinterface.com/wizard/signupWizard.do Notice that if you use MSIE of Mozilla, Back button is not enabled, because session history is not growing. This "clean history" aspect is more important in non-ajax environment, though, because it keeps browser Back button disabled. This is not needed for reloadable ajax modules. I have a simple demo with JSP page where the wizard is used as ajax component. All it took is just two Javascript functions like in Frank's (and others') articles. The handling of error messages is a different feature, see how messages stay when you refresh the page. I am sorry for this shameless plug, I could not help mentioning my own stuff, but my wizard actually has most of the needed features of good ajax component, which can be taken into account as well: * larger ajax component should be stateful * state must be hold completely on the server. No ugly _viewstate, no other hidden fields, no query parameters besides actual data submitted from the page. * no Back button issues * input on POST, output on GET * page is synchronised with the server state * Important usability thing: a user will be able to refresh master page _anytime_ (see, simple static URL pays off). The master page will reload all child components in their current state, without thinking much about parameters that were provided to each component the last time they were loaded. Add to this simple component collaboration API and here you are: portal without portlets. Michael Jouravlev --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
