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". You really should take a look at the URL rewrite filter at 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}"). I think this approach is much cleaner and it does not require a recompile. -- Rick On Mon, May 3, 2010 at 5:46 PM, Nikolaos Giannopoulos < 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> 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> 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 >>> https://lists.sourceforge.net/lists/listinfo/stripes-users >>> >> >> >> >> -- >> Ross Sargant >> Software Engineer >> p: 954-623-6015 x2108 >> email: 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 > >
------------------------------------------------------------------------------
_______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
