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 <mailto:nikol...@brightminds.org>
w. www.brightminds.org <http://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
