Jason Carreira wrote:
Some goals I would hope for:
* declarative security friendly URLs and the ability to protect your
actions from being called.
See the "Action invocation" post. .action URL's should go away with that.
* multiple configuration files, to improve multi-user version control
concurrency
See the "Action configuration XML", and particularly the package idea.
With XML entities you're there.
- 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.
Which is bad because you're displaying the guts of your application to
the user. URL's of that kind will likely be shortlived. No good.
This allows for very fine grained reusable application pieces, which
can be put together dynamically by creating a URL.
You'll get the same with actions calling actions (easy with the new API)
and action interceptors. Except it's all under the covers.
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.
Ok, I see.
/Rickard
--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic
Got blog? I do. http://dreambean.com
-------------------------------------------------------
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
