So another option is the following:
public class MemberActionBean extends BaseActionBean {
@UrlBinding("/member/${event}/{id}")
public class MemberActionBeanEN extends MemberActionBean {}
@UrlBinding("/miembro/${event}/{id}")
public class MemberActionBeanES extends MemberActionBean {}
@DefaultHandler
public Resolution view() {
return new ForwardResolution("/WEB-INF/jsp/home.jsp");
}
}
The only problem is that Stripes does not do well with constructing
ActionBeans that are inner classes (essentially an inner class is a
little weird in that the out class needs to be instantiated first and
then the inner class gets instantiated - overriding something like the
following should do the trick:
protected ActionBean makeNewActionBean(Class<? extends ActionBean>
type, ActionBeanContext context)
throws Exception {
ActionBean bean = null;
Class<?> typeOuter = null;
Class<?> typeInner = null;
typeOuter = type.getEnclosingClass();
if (typeOuter == null) {
bean = (ActionBean) type.newInstance();
}
else {
typeInner = type;
bean = (ActionBean)
typeInner.getConstructors()[0].newInstance(typeOuter.newInstance());
}
return (bean);
}
I tested the above method locally and it works though I do like Aaron's
suggestion... as the major downside with this approach is that each
language specific URI amounts to the instantiation of an outer+inner
class vs. 1 action bean, though it does have the plus side that if there
was some functionality that needed to be handled (slightly) differently
/ tweaked for a given language then it allows for that... .
Also I am not so sure that I wouldn't run into more trouble with the
above when it comes to parameters, validations, etc...
Thoughts?
--Nikolaos
Nikolaos Giannopoulos wrote:
Ross,
Comments in-line....
Ross Sargant wrote:
Yup. No doubt that the solution completely breaks down if you need to
use it with several different parent prefixes.
I was able to get away with something similar b/c I had a very
limited set of mapped functions that were handled by a small number
of action beans. It actually had nothing to do with wanting localized
URLs to reference the same action. I needed the browser URL state to
be correct for resolving relative references to resources "owned" by
the "context" established by the URL and I didn't want to fix at
compile time the list of supported contexts BUT I had action bean(s)
whose logic I wanted shared across contexts.
I figured it wasn't for localization and actually that implementation
crossed my mind but was discounted....
Even if the "natural" way was supported,would you really even want to
hardcode binding associations like that since it guarantees a
recompile to support a new language?
You know what... not too long ago I had that same notion and was
leaning heavily towards resource bundles for the URI's.
However, even if the binding was dynamic there still would need to be
some sort of validation which can also be dynamic but soon you
discover that you are drifting more and more from being able to
leverage the things that simplify making web apps with Stripes... .
Also although it would be nice to add a "new language" on-the-fly the
unfortunate thing is that it sounds great in theory but not in
practice as there is some value to creating a new build version,
running it through the wringer and deploying clean builds (not
patched) especially in large applications which have multiple app
servers across a number of OS containers.
Lastly, we have many countries that support a given language so
extending language support is a big thing and a compile is acceptable.
Just some thoughts....
--Nikolaos
On Mon, May 3, 2010 at 4:58 PM, Nikolaos Giannopoulos
<nikol...@brightminds.org <mailto:nikol...@brightminds.org>> wrote:
Ross,
That's an interesting suggestion unfortunately it won't meet the
requirements as the URLs are set... and in fact /m/ is already
used for the "mobile" webapp... and then what about /member and
/membership... do we go with /m1/ and /m2/??? Gets ugly pretty
fast when you need to "re-engineer" your URLs for the solution to
work. Like you said it isn't very "clean".
Any other thoughts anyone? Someone must have come across this
and beyond simplicity I would hope the reason that Stripes
doesn't support this OOB is b/c it is easily supportable in some
way. Am I dreaming????
Thanks,
--Nikolaos
Ross Sargant wrote:
Hi,
Not totally "clean" but what about just parameterizing the
first component under a common parent prefix?
@UrlBinding("/m/${member}/{$event}/{id}")
public class MemberActionBean extends BaseActionBean {
private String member;
public String getMember(){
}
public void setMember(String member){
}
}
You can easily check if member if "valid" (one of
member,memiembro,/membre) inside your bean.You might even be
able to get stripes to do it for you with built-in validators.
If you stick with using the bean class when generating foward
resolutions, redirect resolutions and links with stripes:link
(good practice IMHO), stripes can handle the rest. You just have
to propagate the current "member" value as a parameter.
On Mon, May 3, 2010 at 1:10 PM, Nikolaos Giannopoulos
<nikol...@brightminds.org <mailto:nikol...@brightminds.org>> wrote:
Hi,
We are building a large site that initially supports 2
languages but
will quickly grow 5+. The site has country specific
"virtualized"
sub-domains i.e. the underlying plumbing is just one site
that accepts
any language based on country specific site or user preferences.
I really like Clean URLs however our MemberActionBean must
accept ANY of
the following URLs:
/member/{$event}/{id}
/miembro/{$event}/{id}
/membre/{$event}/{id}
/membro/{$event}/{id}
Unfortunately the following is not allowed:
@UrlBinding("/member/{$event}/{id}")
@UrlBinding("/miembro/{$event}/{id}")
@UrlBinding("/membre/{$event}/{id}")
@UrlBinding("/membro/{$event}/{id}")
public class MemberActionBean extends BaseActionBean {
Any ideas on how to get something like this to work? We
will have at
least a dozen other action beans just like this.
--Nikolaos
------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Ross Sargant
Software Engineer
p: 954-623-6015 x2108
email: rsarg...@tvrc.com <mailto:rsarg...@tvrc.com>
TVR Communications LLC
541 S. State Road 7,Suite 5,Margate, Florida,33068
http://www.tvrc.com
--
------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
