[Stripes-users] Thoughts on Robust URL Localization in Stripes
Hi, We essentially have tried very hard to abstract URL localization out of Stripes and make it a veneer by using all of the following: - UrlRewriteFilter w/ java class re-writers and hot reloadable resource bundles - An enhanced RedirectResolution (to support redirection to a localized URL) - An enhanced Link tag (to produce a localized URL) - An enhanced Form tag (to produce a localized action URL) All of this appears to work but one more thing is missing. Say my locale is en_CA and someone sends me a link to a Spanish URL. I click on the link and go to the site and the system says ohhh... your locale is en_CA therefore the canonical form of the URL is the same as the incoming URL... ummm 404. Not good. Solution #1: Add shell subclasses of existing Action Beans to support all the localized @UrlBinding variants for each Action Bean ala Freddy's book. As I mentioned before this approach did not bode well for the fact that now localized strings were hardcoded into the code and not entirely encapsulated in something external and reloadable like resource bundles. Solution #2: Add a mechanism that if Action Bean resolution fails progress through each locale (other than the current) and attempt to find a match to a URL binding and if so then forward to that Action Bean... . I think this is the solution we are going to follow for now as we have built all of the above already... BUT... All this re-opens that can of worms of should the Stripes framework know about localization or should it simply be a veneer? And I am thinking that the recent Form tag issues it seems that Stripes isn't happy if we try to blindly impose that veneer AND there is a lot of hard work around Stripes to make that veneer work but it does require a lot of plaster / filler. So what to do... . Solution #3: Augment Stripes to become more URL localization aware... a) Come up with a new localization binding or possibly even an enhanced version of the existing URL binding that say might have a binding expressed as follows for example: @UrlBinding(/[share]/{uuidRadix}/{titleUrlified}/[{$event}]) Where the [ and ] signal a localized key or variable that is looked up in a property file and cached for each of the available locales: localize.url.properties: locales=en,es localize.url_en.properties:share=share $event=view,add,edit,remove localize.url_es.properties:share=compartir $event=ver,anadir,editar,eliminar So in this manner when Stripes processes the annotation it produces multiple bindings, 1 per locale, per action bean and prioritized according the list of locales. Also it would be necessary to provide a mechanism that can purge and hot reload these caches. Thus... now we have the following: - UrlRewriteFilter w/ java class re-writers and hot reloadable resource bundles DOING MUCH LESS e.g. mapping urls /shares == /share/all - An implicitly enhanced RedirectResolution that simply utilizes the current context locale to produce an appropriate URL - An implicitly enhanced Link tag that simply utilizes the current context locale to produce an appropriate URL - An implicitly enhanced Form tag that simply utilizes the current context locale to produce an appropriate URL - An implicit ability to still catch URLs whose localization does not match the users current context locale So essentially instead of having the current One-to-One mapping of URL binding to Action Bean we would have a Many-to-One mapping of URL bindings to Action Beans however the association key is the current locale and if that fails then each of the localized URL bindings could be used until one fully matches. This could also offer the side benefit that if 2 Action Beans have localized URI conflicts then a URL cache process time error could be generated where as currently this is simply a run time bug. Because as much as I would like to see localization as a veneer as we have done now unfortunately it permeates through other areas and now ends up requiring front end rewriter mapping logic coupled on top of Tag and Resolution enhancements and finally Action Beans needed to maintain and support localization... . And I think that this becomes somewhat of a tipping point where the veneer solution appears to need just way too much plaster to maintain and instead could be something the framework can gracefully abstract away and support. What are peoples thoughts on this Solution #3? Any holes in the logic? Opinions (yes I did ask for that ;-) ? Any suggestions, tweaks, etc...? Cheers, --Nikolaos -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company
[Stripes-users] Thoughts on Robust URL Localization in Stripes
Hi, We essentially have tried very hard to abstract URL localization out of Stripes and make it a veneer by using all of the following: - UrlRewriteFilter w/ java class re-writers and hot reloadable resource bundles - An enhanced RedirectResolution (to support redirection to a localized URL) - An enhanced Link tag (to produce a localized URL) - An enhanced Form tag (to produce a localized action URL) All of this appears to work but one more thing is missing. Say my locale is en_CA and someone sends me a link to a Spanish URL. I click on the link and go to the site and the system says ohhh... your locale is en_CA therefore the canonical form of the URL is the same as the incoming URL... ummm 404. Not good. *Solution #1*: Add shell subclasses of existing Action Beans to support all the localized @UrlBinding variants for each Action Bean ala Freddy's book. As I mentioned before this approach did not bode well for the fact that now localized strings were hardcoded into the code and not entirely encapsulated in something external and reloadable like resource bundles. *Solution #2*: Add a mechanism that if Action Bean resolution fails progress through each locale (other than the current) and attempt to find a match to a URL binding and if so then forward to that Action Bean... . I think this is the solution we are going to follow for now as we have built all of the above already... BUT... All this re-opens that can of worms of should the Stripes framework know about localization or should it simply be a veneer? And I am thinking that the recent Form tag issues it seems that Stripes isn't happy if we try to blindly impose that veneer AND there is a lot of hard work around Stripes to make that veneer work but it does require a lot of plaster / filler. So what to do... . *Solution #3*: Augment Stripes to become more URL localization aware... a) Come up with a new localization binding or possibly even an enhanced version of the existing URL binding that say might have a binding expressed as follows for example: @UrlBinding(/*[share]*/{uuidRadix}/{titleUrlified}/*[{$event}]*) Where the [ and ] signal a localized key or variable that is looked up in a property file and cached for each of the available locales: localize.url.properties: locales=en,es localize.url_en.properties:share=share $event=view,add,edit,remove localize.url_es.properties:share=compartir $event=ver,anadir,editar,eliminar So in this manner when Stripes processes the annotation it produces multiple bindings, 1 per locale, per action bean and prioritized according the list of locales. Also it would be necessary to provide a mechanism that can purge and hot reload these caches. Thus... now we have the following: - UrlRewriteFilter w/ java class re-writers and hot reloadable resource bundles DOING MUCH LESS e.g. mapping urls /shares == /share/all - An implicitly enhanced RedirectResolution that simply utilizes the current context locale to produce an appropriate URL - An implicitly enhanced Link tag that simply utilizes the current context locale to produce an appropriate URL - An implicitly enhanced Form tag that simply utilizes the current context locale to produce an appropriate URL - An implicit ability to still catch URLs whose localization does not match the users current context locale So essentially instead of having the current One-to-One mapping of URL binding to Action Bean we would have a Many-to-One mapping of URL bindings to Action Beans however the association key is the current locale and if that fails then each of the localized URL bindings could be used until one fully matches. This could also offer the side benefit that if 2 Action Beans have localized URI conflicts then a URL cache process time error could be generated where as currently this is simply a run time bug. Because as much as I would like to see localization as a veneer as we have done now unfortunately it permeates through other areas and now ends up requiring front end rewriter mapping logic coupled on top of Tag and Resolution enhancements and finally Action Beans needed to maintain and support localization... . And I think that this becomes somewhat of a tipping point where the veneer solution appears to need just way too much plaster to maintain and instead could be something the framework can gracefully abstract away and support. What are peoples thoughts on this Solution #3? Any holes in the logic? Opinions (yes I did ask for that ;-) ? Any suggestions, tweaks, enhancements, mods, etc...? Cheers, --Nikolaos -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business,