Patrick Lightbody wrote:
Great! So we can expect a finished product by Friday? :)
Friday? *yawn* :-)
Will do. I'm afraid I'm gonna thrash around in the current sandbox code quite a lot.Glad to have you on board with this. Of course, I'll be around to help in any way possible -- just gimme a holler.
One thing though: I desperately need to know if chaining needs to be possible given the concept of interceptors. I want to see if there are easier ways to deal with the usecases where chaining is used currently.
Also, I want to establish some design goals. IMHO the end result will be better with more strict requirements.
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
-------------------------------------------------------
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
