> -----Original Message----- > From: Rickard Öberg [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 02, 2003 5:37 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Rethink > > > Patrick Lightbody wrote: > > Great! So we can expect a finished product by Friday? :) > > Friday? *yawn* :-) > > > Glad to have you on board with this. Of course, I'll be > around to help > > in any way possible -- just gimme a holler. > > Will do. I'm afraid I'm gonna thrash around in the current > sandbox code > quite a lot. > > 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.
Yes, For our needs, chaining is very very helpful. More on this below... > > 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 > Some goals I would hope for: * declarative security friendly URLs and the ability to protect your actions from being called. * multiple configuration files, to improve multi-user version control concurrency - In the current (proprietary) framework we use, this is done by having one main configuration file which maps certain paths to certain config files. These sub config files define the request handlers (like actions) and response handlers (like views). The nice thing about this is the way chaining is handled. Below a certain path, which is mapped to a sub-config file, every path segment is treated as a reference to a handler. So, for instance, if we have a sub-section with a separate config file mapped to /foo, this url: /foo/handler1/handler2/handler3 Would look up and invoke handler1, then handler2, then handler3 in that order, and return the response handler (view) associated with the final request handler (action), unless an error is encountered. This allows for very fine grained reusable application pieces, which can be put together dynamically by creating a URL. Unfortunately, the current framework doesn't have the concept of the value stack, and does everything by binding beans into the request. Handlers don't have properties like Actions, but are more stateless and just use the request parameters directly. Jason ------------------------------------------------------- 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
