I think we have to search hierarchy all provided we want to support overridden text (even if you define some convention about location).
So the only solution I can imagine is caching if applicable. Do you get 2075 on each page render or just first? Lukasz said we have caching and you wouldn't get on each render. Regards. On 9/20/2020 12:52 PM, Greg Huber wrote: > James, > > After a rethink I came to the same conclusion, the most efficient way is > to check ApplicationResources.properties first, but as Lukasz points out > the properties cannot be override higher up in the class hierarchy. > Which I guess would be an issue for some. One resolution would be use an > alternative default location, ie in a package.properties in > main/resources/myorg/. Same basic location as > ApplicationResources.properties, but there are now two places needing > maintenance, and could get messy requiring too much testing. > > I will have a look at the text-provider example, but > StrutsLocalizedTextProvider does not look too bad, it is > AbstractLocalizedTextProvider.findMessage(..) which seems expensive, as > it does recursive call in every which way possible. > > One of my screens does 2075 calls to > AbstractLocalizedTextProvider.findResourceBundle(..), with some of the > (needless?) checks for each s:text used: > > Miss : 1519736165com.opensymphony.xwork2.ActionSupport_en_GB > Miss : 1519736165com.opensymphony.xwork2.Action_en_GB > Miss : 1519736165com.opensymphony.xwork2.Validateable_en_GB > Miss : 1519736165com.opensymphony.xwork2.interceptor.ValidationAware_en_GB > Miss : 1519736165com.opensymphony.xwork2.TextProvider_en_GB > Miss : 1519736165com.opensymphony.xwork2.LocaleProvider_en_GB > Miss : 1519736165java.io.Serializable_en_GB > Miss : 1519736165java.lang.Object_en_GB > > > Miss : 1519736165com.opensymphony.xwork2.package_en_GB > Miss : 1519736165com.opensymphony.package_en_GB > Miss : 1519736165com.package_en_GB > > eg limiting these to a hierarchy of > myorg.myapp.whatever.struts2.myAction would help, but messy. > > Cheers Greg > > On 19/09/2020 17:11, James Chaplin wrote: >> Hello Everyone (and Greg, Lukasz and Yasser more specifically). >> >> There are probably differing opinions on what constitutes "best >> practice" for properties/resource bundles and Struts 2, but as long as >> the set-up you use for your application functions effectively for you, >> it is probably OK. I find having a single set of global properties >> convenient and easy to read, but it might not be as flexible as having >> multiple/hierarchical property files. >> >> Greg's proposal to change the order of lookup (scan the global >> ApplicationResources.properties first) is interesting, but might have >> some unintended impacts to applications whose behaviour depends on the >> current lookup order. If there is a way to introduce the idea without >> impacting preexisting applications, that would be ideal. >> >> I wonder if providing an opt-in (either by configuration flag or >> specifying the provider/factory) LocalizedTextProvider variant, with a >> lookup order change similar to what Greg proposed, might be a >> reasonable compromise ? >> >> Since the current default LocalizedTextProvider does its >> look-ups "bottom-up", the new variant (or existing one with behaviour >> modified via configuration flag) could do its look-ups "top-down" >> (starting at the global ApplicationResources.properties and then >> proceeding in an opposite order to the current default). Essentially, >> it would be more efficient for single-property-file applications, as >> in Greg's scenario (vs. the existing one which is more efficient for >> class/hierarchy text). >> >> Since developers can implement their own LocalizedTextProvider >> instances (the Struts Examples >> https://github.com/apache/struts-examples/ text-provider example >> provides a starting point), the Struts 2 Core should probably only >> need to cover the most common usage patterns. There is already a >> GlobalLocalizedTextProvider implemented, but it only looks at the >> global application bundle (so its JavaDoc comments are misleading). >> >> What do you folks think ? >> >> Regards, >> >> James. >> >> On 2020/09/15 08:16:53, Lukasz Lenart <lukaszlen...@apache.org> wrote: >>> wt., 15 wrz 2020 o 08:41 Yasser Zamani <yasserzam...@apache.org> >>> napisał(a): >>>> Hi Lukasz :) >>>> >>>> Excuse me... do you remember the place where caching occurs please? I >>>> found some references of StrutsLocalizedTextProvider.getText and >>>> followed up their parents. Also saw TextProviderSupport.java. I >>>> couldn't >>>> find any cache for founded text :( Maybe because it's dependent to >>>> current valueStack and cannot be cached (?) >>> This is combination of bundlesMap and missingBundles, also please be >>> aware that ResourceBundle.getBundle() does caching as well >>> >>> >>> Regards >>> -- >>> Łukasz >>> + 48 606 323 122 http://www.lenart.org.pl/ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
