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> 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/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> 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 >>> >>> >>> >
------------------------------------------------------------------------------
_______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
