Rick,
Comments in-line....
Rick Grashel wrote:
Nikolaos,
To my eyes, this seems to be a situation where you are trying to use
Stripes for something that it isn't intended to do. Nor should it
perform this function.
The moment I saw your requirement, I instantly thought : "URL Rewriting".
We have architected an RP layer using Oracle Web Server (used to be Sun)
7.0 for s/w LB'ing and originally planned to do RP mapping and I have
done this before for other clients so it isn't a technical issue.
Typically in the RP we would setup for each mapping (1) relative forward
mapping, (1) absolute forward mapping and (1) absolute reverse mapping
to handle redirects to reverse localize.
You really should take a look at the URL rewrite filter at tuckey.org
<http://tuckey.org>. http://tuckey.org/urlrewrite/. By doing a URL
rewrite *before* the StripesFilter is engaged, you can rewrite the
inbound URL to match the Stirpes @UrlBinding. For example, in my
urlrewrite.xml, I might have the following to meet your rule:
<rule>
<from>/m/miembro/(.*)</from>
<from>/m/miembro/(.*)</from>
<from>/m/membre/(.*)</from>
<from>/m/membro/(.*)</from>
<to>/m/member/$1</to>
</rule>
Now, with that single rule, you take care of the multiple URL bindings
for the StripesActionBean with a binding of
@UrlBinding("/m/${member}/{$event}/{id}").
OK it would work for Forward resolutions but what about mapping back to
localized Redirect resolutions. No matter how you cut it localization
starts becoming more and more something the web app needs to know about
OR at least a piece of information needs to be retained before AND after
in case a Redirect URL requires massaging.
I think this approach is much cleaner and it does not require a recompile.
True compilation is not required and all you need to do is maintain some
mapping files but what I have seen first hand in production systems is
mapping files getting messed up accidentally and things all of a sudden
not working properly OR mapping files on some systems updated but not
updated on say 1 system and then intermittent headaches.
Of course proper version control is a must and if that isn't happening
then its another problem altogether however updating and maintaining a
WAR on say 6 app server instances PLUS localized mapping files on say 8
RP instances vs. managing that localization with a WAR on say 6 app
servers and giving up compilation is not so cut and dry IMHO.
Looking at this further my bad but I totally failed to mention that the
${event} will also require localization e.g.: /member/${event}/{id}
where ${event} is either "view", "edit", "save", and "delete"
/miembro/${event}/{id} where ${event} is either "ver", "editar",
"guardar" and "eliminar"
...
Now that introduces yet another interesting wrinkle....
Good conversation in any event :-)
--Nikolaos
-- Rick
On Mon, May 3, 2010 at 5:46 PM, Nikolaos Giannopoulos
<nikol...@brightminds.org <mailto:nikol...@brightminds.org>> 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
