Stop automatically preprending moduleId to the start of message properties

Moving discussion from TRUNK-3920

Currently, the module framework prepends your moduleId to the start of all message property keys that don’t have them. (E.g. if I say in “yes=Yes” this gets converted to “mymoduleid.yes=Yes”.)

Unless you have a (hacky) message code saying “” in which case the moduleId is not prepended.

I propose that we get rid of both of these behaviors.

The first behavior is nonstandard, and confusing, and the goal it is trying to achieve is misguided in the first place.

The second behavior is hacky but required to get around the first behavior (e.g. if you want a “distribution module” to define message codes for other modules, or to do l10n of metadata), and it doesn’t work with i18n tooling like transifex (because a translator will just translate “true”, thus breaking the behavior).

Unless anyone argues convincingly that these behaviors should stay, I am going to rewrite TRUNK-3920 to reflect removing these behaviors.

(This will cause minor backwards-compatibility problems for some modules that are relying on the first behavior, but these will be immediately-visible, and trivially easy to fix. In any case, we should do this as part of the Platform 2.0 release.)

1 Like

I welcome this change!

So how will you handle conflicts? I.e where different modules and core have same message codes? Do you intend to validate them and ensure there are no duplicates to override each other?

Good question.

I would hope that modules are able to override core messages, and this just naturally works. So, no, we should not validate duplicates.

(I don’t think we need to solve the situation of trying to ensure deterministic behavior if two modules try to define the same code. If we were to solve that it should go via module startup order.)

1 Like

If everyone else agrees with that, then it its fine by me

Sorry for coming late to this, but I’m a little confused. If we are eliminating namespacing of message bundle keys, what will be preventing conflicts between keys? Will the framework know which module code is requesting the message? Or will it just be random, depending on which module was loaded last? Do we identify the module when requesting a message?

For example, imagine I had 30 modules that all used different messages for the key title, how would the right title be rendered for each module?

The idea is that you should still namespace message codes, but that the module framework won’t automagically prepend the moduleid as a namespace if you haven’t already. (Because this is non-standard, confusing, and it prevents you from defining codes outside your namespace, which we sometimes want.)

It’s already the case that the archetype and basic module start you off with something like this:

${project.parent.artifactId}.title=Your Module

So most modules are already adding the module id themselves already.

It makes a lot of sense!

So then the general advice to module developers is to ensure that message codes are namespaced but the module framework will no longer do this automatically? Is there any estimate for when this change expected to be released?

@ibewes, it will happen with OpenMRS Platform 2.0 (we haven’t exactly decided when that will be), and you will have sufficient advance warning.

I have sent a PR at [1]. Please review it and let me know any issues. After the removal of this behaviour, I thought that there is no need of test method WebModuleUtilTest.copyModuleMessagesIntoWebapp_shouldPrefixMessagesWithModuleId. Hence I removed it. Please correct me if I am wrong.

Also please provide the wikis that you know which has to be updated regarding this. I will also go through to find out. :smile: Still a newbuddy, so still getting to know things. :smile:

1 Like