This could work ok, especially if there were a configuration file such
that the jsp to forward to could be specified on a per action/result
basis, which would prevent having to duplicate jsp files unnecesarily. I
would consider this, but unfortunately I am mostly using a result type
of "tiles" to hand over to Tiles2 for view generation. In theory I could
modify the tiles handler to support this..
I'll have to dig into Tiles code and maybe some struts code and see what
can be done.
Gabriel Belingueres wrote:
Another direction would be to try implementing your own Result type:
<action name="login" class="mypackage.LoginAction">
<result name="success"
type="myCustomDeviceDependentResult">index</result>
</action>
Then the result would check the device type the user is accessing the
application with, and you can try searching first for a:
index_brand_model.jsp, and if not found search for:
index_brand.jsp, then
index.jsp
When you find the right JSP page, just forward to it like the
ServletDispatcherResult do.
(I'm sure Convention plugin must have something like this already working.)
2010/1/29 Marcus Bond <mar...@marcusbond.me.uk>:
Interesting, I hadn't thought of that. However a problem I see here with
this approach is that it implies that there would be different versions or a
different mapping for every view whereas in reality, if a page looks / works
fine on say iphone, htc, windows mobile but doesn't on an old blackberry
then I want to be able to create a tweaked page for one device, but all
others would use the same page and mapping.
Gabriel Belingueres wrote:
How about using different packages/namespaces for the views?
<package name="package_blackberry" namespace="/bb">
<action name="login" class="mypackage.LoginAction">
<result name="success">/bb/index.jsp</result>
</action>
</package>
<package name="package_winmob" namespace="/wm">
<action name="login" class="mypackage.LoginAction">
<result name="success">/wm/index.jsp</result>
</action>
</package>
2010/1/28 Marcus Bond <mar...@marcusbond.me.uk>:
Hi,
I am wanting to implement a site such that some actions may have a
different
mapping depending upon the device used (e.g. regular browser / mobile
device
etc.) but what I don't want to do is have to litter my actions with this
type of logic. It could be at the result mapping level (i.e. in
struts.xml)
such that say a result of success would map to a jsp of somePage.jsp for
regular browsers and somePageMobile.jsp for a mobile device (there will
be
more complications to this as I'd like to be able to have fine grained
control based on the user agent so there may be many versions of a jsp
such
as somePageWinMobile6_5_htc.jsp).
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.
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?
Any suggestions here are greatly appreciated!
Web technologies being used are Struts2, Tiles2 and JSP.
Regards,
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
__________ NOD32 4818 (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
