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, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
