Resouce Bundle update - best practices

Experience Manager (PaaS/OnPrem)
1

Hi everyone,

i wanted to ask the community for feedback on an ever recurring issue that we are facing in many of our BloomReach projects. We are making extensive use of Resource Bundles to manage static texts and labels in various areas of our pages.
However, once those resource bundles are deployed on a production environment, they are treated as regular content (as expected). This makes it tricky for us to extend and upgrade existing resource bundles when deploying new releases of the system.
Consider the usecase that we want to add a new label to an element on the page and for consistency and editor friendliness want it to reside in an existing resource bundle. As the resource bundle already exists we cannot reload it via a hcm-actions entry as this would eliminate potential changes made by the editors. At the same time we need the value to be present once the new version is deployed if we don’t want a ???my_tag??? text popping up on our site as the fmt:message tag does not really support defaults.

We already came up with different ideas how to manage this and are really interested if the community or the BloomReach Devs have other interesting ideas or best practices to properly solve this:

  • Manually add the new resource bundle key before deployment: This is very undesirable as we strive to completely eliminate manual steps in the deployment process to achieve a real CD environment.

  • Add a custom template macro / tag that provides the option to replace a missing value with a default (by checking if the value from the resource bundle contains the ??? substring): This is also undesirable as it does not offer multi language support and clutters the template with unnecessary default texts

  • Reading all resource bundle values in components / Java code and replace with defaults where necessary: This again is undesirable as we lose the option of using the provided fmt:message tag and also have to keep the defaults somewhere which produces ugly code and is not multi language safe

  • Writing custom updater Scripts that add new keys to the resource bundle: Again, we believe this to be undesirable as Updater Scripts are yet another manual step during deployment and can potentially cause significant bugs. Also, the developers have to keep track and update the script (or its parameters) for every deployment which is quite error prone

So if you have any other approach to this, we would greatly appreciate any feedback on this!

All the best,
Felix

2

Hi Felix,

How about reloading resource bundle docs with reload action settings?

Regards,

Woonsan

3

Hi Woonsan,

thanks for your quick reply. However, as I described in my post, reloading the document with a reload action won’t really do what we want as it is quite possible that the already existing values were changed on the target environment by the editors. In that case the changes would be lost if we would override the entire document with a reload action.
To make this work, we would have to backport the currently running version to development first to make sure that we don’t loose any changes made by the editors.

Does that make sense?

All the best,
Felix

4

If you don’t want to lose resource bundle content on production, but if you add new resource bundle pairs in new releases, then there’s another convenient option:

  • Configure multiple resource bundle ids as comma separated strings everywhere. i.e. @hst:defaultresourcebundleid on hst:virtualhost or hst:mount, @hst:resourcebundleid on hst:sitemapitem, or basename attribute in <@hst.setBundle basename="..." />.
  • Put the resource bundle id(s) (a.k.a. basename) of the resource bundle documents, which editors may edit, first in those properties or attributes, and put another bundle id(s) - including what devs may provide as defaults - after that. e.g. @hst:defaultresourcebundleid = "com.example.messages, com.example.messages.default"
  • Then HST will handle fallbacks automatically by trying to find a value from the first bundle, and from next until it finds one, … It internally uses org.hippoecm.hst.resourcebundle.CompositeResourceBundle for that.

Regards,

Woonsan

5

BTW, not every resource bundle ID has to be from resource bundle document. It can be just normal standard java resource bundle resource from the classpath. So, com.example.messages.default can be put in either a specific cms admin folder (not to be edited by editors) or a java resource file in a jar for example.