Turns out that what I set out to do in solution #3 in fact was quite
simple and appears to work well.
For anyone interested here is what it involves:
1) Create a class that extends the Stripes FormTag... and when building
the action simply uses the overrideUrl attribute - if set - and still
does all the normal Action Bean binding...
public class *FormTag* extends *net.sourceforge.stripes.tag.FormTag *{
private String overrideUrl = null;
public void setOverrideUrl(String overrideUrl) { this.overrideUrl =
overrideUrl; }
public String getOverrideUrl() { return overrideUrl; }
@Override
protected String buildAction() {
String action = null;
if ((this.overrideUrl != null) && (this.overrideUrl.length() > 0)) {
action = this.overrideUrl;
HttpServletResponse response = (HttpServletResponse)
getPageContext().getResponse();
return response.encodeURL(action);
}
else {
action = super.buildAction();
return action;
}
}
}
2) Copy FormTag TLD definition to your projects TLD definition AND add
an optional "overrideUrl" attribute definition
3) Switch from using the stripes Form tag to your projects Form tag AND
add the "beanclass" and "overrideUrl" attributes e.g.:
*<a:form*
beanclass="org.test.ui.web.action.content.ShareActionBean"*
overrideUrl="${actionBean.formPostUrlBinding}*" method="POST">
...
*</a:form>*
Enjoy.
--Nikolaos
Nikolaos Giannopoulos wrote:
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
--
Nikolaos Giannopoulos
Director of Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
------------------------------------------------------------------------------
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
