I have a setup where with brXM where some resource bundles have been added manually in the production CMS that I’d like to have their definitions added at least partially within application data for bootstrapping. Initially the use case is to add in an additional key-value pair into an existing resource bundle if possible. I came across the concept of an “add operation” in the YAML Format document but there are no practical examples of how to use this on an existing document and it’s properties. Perhaps this could be used to add a specific key and value to a an existing Resource Bundle?
In this example however it’s unclear to me how to actually add this into the YAML structure. Is add-values-property supposed to be a fictitious property name in the content or is it something meaningful to invoke the add operation? If add-values-property is supposed to be the property I want to modify then what is value a specially named property as well that is supposed to be placed structurally as a child of the original property along with the operation type property? The documentation is quite unclear and seems to assume more in depth knowledge on how this works in order to use it. A more practical example, perhaps related to one of the tutorials or example code bases would likely be very helpful.
Since the project I’m working on takes over 9 minutes to build and about 13 minutes to start up I’m not excited about the idea of trial and error in order to figure this out and would appreciate any insight that anyone may have.
It’s used within some custom directives that are used in .ftl files. Sorry I always forget what is meant by “delivery-tier” as I’m always thinking CMS or Site as the general terms that the developers use when working with Hippo/brXM.
I realized though that the add operation feature that I was trying to use is exclusively meant for “configuration sources” and not for “content sources”. Since we are currently using a Resource Bundle I understand that this puts it into the category of “content sources” which do not have these fine grained operations supported. To go a different direction I’m trying to move the one resource file into it’s own “content source” .yaml file and then explicitly telling that one “base-node” to reload via the hcm-actions.yaml. So far it doesn’t seem to be working for me though. I’m going to have to try again paying closer attention to the logs. The startup time is quite slow so likewise is the iterations of this troubleshooting.
If it’s only about delivery-tier (site) application usages, then you can combine multiple resource bundle documents into one resource bundle in application.
For example, <@hst.setBundle .../>  allows to set multiple basenames to include multiple resource bundle documents in a single ResourceBundle object as a comma separated string.
If your custom tag simply uses the localization context set by the tag, then it can resolve messages by that.
So, if the use case can be covered by resolving messages from the user’s resource bundle document(s) first and falling back to the resource bundle document(s) bootstrapped by developers separately, this feature might be helpful.
Well the use case is that a specific resource bundle had been created by hand through the CMS content perspective which we use to hold configuration values for logic used elsewhere in the system. We are not using it truely for “messages” as resource bundles were originally intended but more of an adhoc key/value store. Normally when we have new configuration key/value pair combinations that we need to deploy we just do these by hand for the initial default values but having to do this in several staging environments as well as production by hand becomes tedious so we figured we’d look into what mechanisms we have available for either adding key/value pairs to existing resource bundles or less desirably replacing the content of a single resource bundle at deployment time through the bootstrapping process.
So far, going the route of separating the single resource bundle into it’s own “base-node” / “content source” based on the auto export documentation on Dynamic Resource Bundle Node Structure (we are actually using v13) and using hcm-actions.yaml to reload the specific content path to our resource bundle we have yet to get this to work. I’m suspecting that the issue may just be related to the several other bootstrapping errors that we have become accustomed to ignoring over the last few years as nobody really understood the significance. It looks like to me now that we may have attempts to update configuration values which are not “categorized as content” in previous version sections in hcm-actions.yaml which I’m guessing may be contributing to other parts of the bootstrapping from being skipped. One thing that I’m trying to sort out right now is whether it’s actually expected or supported to specify non-content node actions in hcm-actions.yaml since based on it’s location (not under the content subdirectory) and it’s name, it doesn’t appear to be meant to apply exclusively to content. In short, we may need to clean up and fix other bootstrapping problems before we can really tell whether we are doing this correctly or not.
On another note the ResourceBundleUpdater looks pretty interesting from our use case the comment on this other thread linked below.
What I’m also wondering is whether the ability to separate resource bundles into their own “content source” files is something only supported in v14 and up. As we are using v13 I had assumed that this would work and that the documentation was suggesting that the auto export feature only works this way by default in v14.
Exporting resource bundles into separate files works only if the resource bundle is created in the /content/documents/administration folder. The new bundle should be created either in the administration folder or in any folder inside the administration folder. Two level inner folders are supported in the administration folder.
It seems to me that when I placed new resource bundle content sources under /content/documents/administration/labels/ both in terms of repository structure as well as folder structure that it wasn’t picked up by the bootstrapping processes at all. This is also with a deliberate section in hcm-actions.yaml to force that resource bundle to reload.