Hi all,
I explored work around *Solution #1* (see e-mail below) which
essentially is the simplified code:
<s:form class="x-form"
action="*${actionBean.formPostUrlBinding}*" method="POST">
...
<s:hidden name="*toUrl*" />
...
</s:form>
Such that it produces the following simplified snippet:
<form action="*/ui-web/share/0/_*" class="x-form" method="POST">
...
<input name="toUrl"
value="*/ui-web/compartir/0/_/anadir*" type="hidden" />
...
</form>
And Stripes is happy with the binding HOWEVER upon massaging the source
page / resolution it became obvious that as the user posts to:
/ui-web/share/0/_
if a validation error occurs I would need to do a "*RedirectResolution*"
vs. Stripes current "*ForwardResolution*" to get the user back to:
/ui-web/compartir/0/_
This NOW produces other grief... such as the fact that on Redirect
Stripes does not maintain the errors (but does maintain messages) so now
I would have to augment the redirect mechanism to use the flash scope to
maintain errors on top of having the user POST a non-localized URL and
do redirects... this is getting uglier by the minute... .
So it appears I am damned if I do and damned if I don't... damned if I
appease Stripes... i.e. damned if I don't appease Stripes as it works
against the Stripes grain... .
*Solution #2 *outlined in the e-mail below - while it would work and is
in Freddy's book is simply totally backwards as it hard codes
localization back into the classes of the app which defeats the
abstraction / separation of localization from code and defeats the
entire purpose of all the localization that was built with
UrlRewriterFilter and resource bundles... .
*Solution #3* (just thought of) is something I am going to try next...
HACK Stripes form tag to accept an "overrideUri" attribute such that it
can do all the lovely binding stuff it wants to but the URI that gets
populated in the "action" will be the contents of "overrideUri" IFF
specified (thus keeping things backwards compatible). I would also use
"beanclass" to help Stripes point to the ActionBean. So in the end, let
Stripes do its magic just point the user back to some other URI for the
purposes of the "action" of the form. Fingers crossed... .
Stay tuned... .
--Nikolaos
Nikolaos Giannopoulos wrote:
Hi,
*/_Setup:_/
*
- ShareActionBean with
@UrlBinding("*/share/*{uuidRadix}/{titleUrlified}/{$event}")
- UrlRewriteFilter that pre-processes requests and maps say the
Spanish URL:
*/compartir/0/_/anadir* ==> */share/0/_/add*
/_*Flow:*_/
- User request: */compartir/0/_/anadir*
- UrlRewriteFilter forwards to: */share/0/_/add*
- ShareActionBean event handler simply does:
return (new*
ForwardResolution*("/WEB-INF/jsp/content/*share_form.jsp*"));
- *share_form.jsp* relevant snippet contains:
*<s:form* *action="${actionBean.formUrlBinding}"* method="POST">
<s:text name="share.title" />
<s:hidden name="*tokenKeyTx*" />
<s:submit name="yes" /><s:submit name="no" />
* </s:form>*
- *${actionBean.formUrlBinding}* resolves to */compartir/0/_ *so
the form tag ends up looking like:
<form action=" */compartir/0/_*" method="POST">
<input type="text" name="share.title" value="" />
<input type="hidden" name="*tokenKeyTx*" value="" />
<input type="submit" name="yes" value="yes" /><input
type="submit" name="no" value="no" />
* </form>
*- Now, what happens next was somewhat unexpected... as soon as the
form tag is processed the following error comes up:
ERROR net.sourceforge.stripes.tag.FormTag.error - Could not locate an
ActionBean that was bound to the URL [/compartir/0/_]. Without an
ActionBean class Stripes cannot determine whether the ActionBean is a
wizard or not. As a result wizard behaviour will be disabled.
- While I understand that Stripes is trying to make a 1-to-1
association between the form action and an existing URL binding the
problem is that the error appears to affect the binding of the
"tokenKeyTx" hidden field in the form in that it ends up with a value
of "" instead of its true value "83e32-32435254-sjfi-asbsdrwq".
I could probably live with an error being logged but why does Stripes
make this such a serious offence AND in light of localization isn't
this a problem???
I see 2 immediate workarounds to this problem though both aren't great:
1) Use non-localized action URL in the form but then I would need to
override Source page resolution b/c if there is an error in say user
input the user must be redirected to the localized version of the URL
and not the non-localized version. As well in order to maintain the
localized URL which could contain an id for example (say doing edit)
we would need to add a hidden form field for the localized URI... this
smells in that the URL in the action is non-localized and although not
directly visible to the user still appears silly to be part of a fully
localized web app and then we pack a hidden localized URI. Uuuggghhh...
2) Add URL bindings for localized versions. This is not viable as we
are using UrlRewriteFilter to abstract localization from our
components and have invested heavily to abstract as much of that away
from Stripes as possible.
Thoughts? Other Solutions? Is this a flaw? Bug (in light of
localization)?
Thanks,
--Nikolaos
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
