On 5/27/07, Don Brown <[EMAIL PROTECTED]> wrote:
In Struts 2.1 (and XWork 2.1), I'm thinking about reworking how we process
urls and convert them to actions. Specifically, I want to make it possible
for the Struts 2 dispatcher filter to potentially examine every request, and
if no action is found, pass control down the filter chain. The goal of this
improvement would be so that Struts 2 could intercept /* but not look for
any particular file extension. This would allow a Struts 2 app to be able
to use the .html extension, but still support static html files.
The primary use case I have in mind is a friendly restful application. This
app has urls like:
http://example.com/book/War+and+Peace
Only you want to serve up different views of the action simultaneously:
http://example.com/book/War+and+Peace.xml
http://example.com/book/War+and+Peace.html
http://example.com/book/War+and+Peace.json
The most natural way to do this is to use the extension. However, if you
have Struts 2 handle all requests, currently, you can't then have it serve
any static files (Dojo, css, etc) and you can't use your web application
server to serve static files either (html, css, js, etc).
The workflow I envision goes like this:
1. Filter matches all URLs (/*)
2. ActionMapper determines the action name and namespace, if either a) an
extension is defined or b) all extensions are configured to be processed
3. The _dispatcher_ tries to find an ActionConfig from the Configuration
(currently this happens in the ActionProxy)
4. If an ActionConfig can be found (even trying the UnknownHandler), the
request is processed as usual by Struts 2 as an action
5. Otherwise, the filter sees if it is an internal Struts 2 resource to
return and does so
6. Otherwise, the filter lets the request go down the chain
To match the example urls above, you would configure Struts 2 to not use an
action extension. Then, in your action, you could match urls that include
the extension:
<action name="book/*.html" class="com.example.BookAction">
<param name="id">{1}</param>
<result>viewBook.jsp</result>
</action>
From here, we could later do interesting things like:
<action name="book/*.*" class="com.example.BookAction">
<param name="id">{1}</param>
<result name="success-html">viewBook-html.jsp</result>
<result name="success-xml" type="xstream" />
<result name="success-json" type="xstream-json" />
</action>
Using a dynamic proxy for the Action that manipulated the returned result
based on the url extension. I'm getting ahead of myself, but you get the
idea of where I'm going with this.
Thoughts?
Don
Isn't this gonna lead to overprocessing inside the framework?
./alex
--
.w( the_mindstorm )p.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
