> -----Original Message----- > From: Rickard Öberg [mailto:[EMAIL PROTECTED]]
> Here are some that I can think of: > * Try to avoid .action URL's > * Allow for multiple read-actions to be on the same page (HMVC) > * Allow for multiple forms to be on the same page, and be developed > independently (the portal case). This essentially means that > parameters > need to be prefixed so that they don't clash. > * Allow write-actions to be performed before a page starts rendering, > but then make the result of that action available DURING rendering. > * Minimize coupling to servlet environment. XWork will > probably still be > a framework that is used mostly for web stuff, but it must be > possible > to use it in a non-servlet environment too. Having multiple > dispatchers > from the start is a great way to ensure this. > * Allow sharing of view code between different views > * Make it trivial to implement Portlets (JSR 168) using > XWork. This is a > personal pet peeve, but I think you'll love it once the Portlet API > solidifies later this year. It's a great thing I think. > > /Rickard Some of the lifecycle and multi-component stuff here sounds a lot like Java Server Faces. I just finished reading the two articles on JSF at onJava.com: http://www.javaworld.com/javaworld/jw-11-2002/jw-1129-jsf.html http://www.javaworld.com/javaworld/jw-12-2002/jw-1227-jsf2.html I must say, I'm underwhelmed in a lot of areas, especially with how much processing has to be done for every request and the heavy dependency on JSP and the web, but the potential for real tool support is very appealing. What are people's thoughts on supporting JSF with Webwork, perhaps with a different Dispatcher? ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
