Thanks for the info Andy, the interceptor seems an appropriate thing
although it does mean there are multiple mappings in struts.xml. This
seems at least a way that allows a site to grow in terms of new views
without impacting upon the application code or exisiting views.
Thinking about it this could be made generic with a little design such
that this result modification could be defined in (yet) another xml
file, all it would really need in my case (as there are not any security
checks to do and it is just a mapping) is to know for each action /
result pair an alternative result to return.
New class (say UserAgentResultListener) and a config file something
along the lines of that shown below, perhaps allowing use of regular
expressions for user agents..
<result-intercept action="myaction">
<result value="success">
<alternative>
<user-agent>*blackberry*</user-agent>
<result>success_blackberry</result>
</alternative>
<alternative>
<user-agent>mobile6*</user-agent>
<result>success_windowsmobile</result>
</alternative>
<alternative>
<user-agent>foo</user-agent>
<result>bar</result>
</alternative>
</result>
</result-intercept>
I can imagine others have had to do something similar in terms of
delivering different views to the same action depending upon user agent
so it would be good to get some community involvement.. I'd happily code
it up.
Marcus
Andrew Sykes wrote:
There are couple of ways I can think of to do this, but they're ugly:
- JSP level logic to render the page differently - dont want it, I'd
rather individual jsp's for each supported device (or family) as this
allows developers who are working on targeting a site to a specific
device to concentrate on that device.
- Tiles template level logic - again not ideal as I would like to be
able to use specific templates for device types.
As you rightly say, this is a maintenance nightmare.
Better but not perfect would be some sort of post action result
modifying interceptor such that in the struts.xml I could define a
number of different result mappings such as success, success_winmob,
success_blackberry_storm and have the result string that has been
returned from the action (success) modified by some sort of interceptor
(e.g. appending the suffix prior to struts mapping it off to a view) -
the filter itself could be configured as to whether or not to alter
result strings based on the action and the user device. - Is it possible
to modify the result string post action but prior to struts resolving
the mapping? And if so would I have access to the the name of the action?
You can attach PreResultListeners[1] onto interceptor & action stack
executions. These execute after an action is executed, but before the
result is rendered. At this point, you are free to reach in and fiddle
with the action's returned result code. You can get the action's name if
you require, and manipulate the action in any way - it can be fetched from
the ActionInvocation.
I've used this feature in the past to perform a final "security
checkpoint" on any item being pulled from a database - the
PreResultListener examines the action (by reflection or otherwise) to find
the object, and checks the user is allowed to retrieve it.
Your idea is probably the sanest way to do it. Write an interceptor[2]
that gets the HttpRequest[3] object, and examines the user agent to
determine what kind of device is making the request. Then it attaches an
appropriate PreResultListener to the stack (for example, you could have
individual subclasses for each device type, and maybe configure them with
a string representing the version, which the PreResultListener uses in its
internal logic).
The PreResultListeners examine the action's result, and if it's success
they modify it to success_devicetype_version, which corresponds to the JSP
/WEB-INF/jsp/devicetype/version/success.jsp, for example. The only ugly
part of this is you'll have lots of results defined for each action in
struts.xml, but at least you have sane separation of your JSPs.
HTH,
Andy.
[1]
http://struts.apache.org/2.1.8.1/docs/can-we-access-an-actions-result.html
[2] http://struts.apache.org/2.1.8.1/docs/interceptors.html
[3]
http://struts.apache.org/2.1.8.1/docs/how-can-we-access-the-httpservletrequest.html
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
__________ NOD32 4817 (20100129) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
