Rick,
I don' think you are missing anything. I think I finally see the light
and you really are suggesting a VERY good solution. Appreciate the well
thought out discussion and the fact that you continued in this lengthy
discussion. Much appreciated.
We will still always have our RP layer and do some mapping there for
various things such as for example the following URLs and that is why I
kept coming back to leverage it for localizing URLs as well but now
realize that it didn't really belong there and 2 re-writer
implementations - albeit for different things (i.e. RP for the following
URLs and UI re-writer for localized URLs) - is "OK":
/m --> /ui-mobile
/ --> /ui-web
But what I "really" like about your solution is that the localization of
URLs AND resource bundles is encapsulated in the UI layer and is
insulated around and independent of the framework. That solution not
only reduces the number of ActionBeans and event definitions but it also
has the bonus of not requiring compilation. I'm going to go with this
solution and will see how it goes.
Thanks Again,
--Nikolaos
Rick Grashel wrote:
Nikolaos,
> 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 might be missing something, but it seems that you only need two things:
1) You need a filter to handle inbound requests. The filter should
run prior to the StripesFilter and it's whole purpose is to massage
the incoming URL into its "canonical" form (which is the
@UrlBinding). Also, the filter should add the original URL
information for reverse resolution. This "localization" of the URL
could run off of a simple dictionary/mapping file.
2) You need a new kind of Resolution. Call it "LocalizedResolution".
The localized resolution takes a "canonical" URL and a locale. Given
the locale, the LocalizedResolution will lookup the localized URL in
the same dictionary/mapping file that the filter uses.
It seems like that should handle everything you need. Then, all you
need to maintain is the localization mapping files
Regardless of the solution you end up with, you really should settle
on a solution that does not require the adding/changing of code in
order to add a locale. Rather, you should settle on a solution that
requires the simple manipulation of property/dictionary files -- and
not code.
-- Rick
On Mon, May 3, 2010 at 10:37 PM, Nikolaos Giannopoulos
<nikol...@brightminds.org <mailto:nikol...@brightminds.org>> wrote:
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
--
Nikolaos Giannopoulos
Director, 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
------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
