> 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
