Philosophy on LegacyUI backward compatibility with modules

I intentionally did not invest time in deleting the files after the module is stopped because of priority. Meaning that i wanted for first finish other MUST tasks before resorting to this, which we can live with. This is the same reason i did not take time to change the urls back to their original values.

About accessing the ServletContext from the activator, i can give it a short. But frankly i feel we should get back to this after we are done with other more important tasks, as long as what we already have works well. :slight_smile:

I agree with @dkayiwa’s prioritization choices. (Also, generally, I don’t see why we should do extra work to invoke this from the activator, which is not Spring-managed, vs what Daniel did, which should happen on context refresh.)

Personally I think of this as more or less a hack (though not a bad one) so it doesn’t bother me that we are copying, and I would vote against doing extra work to move the files instead.

But it ought to be a trivial search-replace to switch the include paths back, and someone can do this in an hour as a new ticket, so we can choose whatever convention we want to have in the legacyui module. (The argument for leaving it as the 
/module/
 path is that it would allow us to remove the hack someday far in the future, by establishing the convention that going forwards any new code should reference the legacyui module, rather than presuming we’ll be copying things directly into WEB-INF.)

I agree that it can be put off, in any case when this module is stopped, the only way to start it is to restart OpenMRS since the manage modules page wouldn’t be present.

Agree w @darius that there is an advantage to leaving the /module/legacyui paths alone in case we can remove this workaround in the future. Plus it is far more intuitive to work with resources that are deployed to the correct module locations. I think it would be fine to establish a convention that code and spring xml reference the correct paths wherever possible (so everything in legacyui stays as-is), and the workaround locations are mostly for module JSP includes and scripts / css. These use cases can be worked out and documented as we go through the process of updating some modules to use legacyui.

I think it would be good to do a spike on converting a module or 2 to use legacyui on platform 2 and make sure it is backwards and forwards compatible. Any thoughts on a good candidate to put into the sprint?

I thought we’d done things such that modules won’t need to be converted, and they’ll just transparently be able to run against platform 1.x or platform 2.x with legacy UI.

If we want to test a couple modules as a proof of concept, the two most commonly used modules are probably HTML Form Entry and XForms, so I’d vote for trying them.

We have to keep in mind the difference between adminui and legacyui modules.

My understanding is adminui is the module that will be containing the administration features of OpenMRS going forward. legacyui is mainly being maintained for backwards compatibility. In other words, legacyui is only being maintained for implementations not ready to switch to adminui and will be eventually phased out.

Another thing is the administration features of OpenMRS are not so much of a service. It is possible to create forms that incorporate administrative features, however, for most purposes, administrative features will be handled directly by the administrative ui, whether it be adminui or legacyui.

@jdegraft, apologies, but I don’t understand where you are going with that comment


We’re talking about Platform 1.x versus Platform 2.x + Legacy UI.

This is tangential to people running the Reference Appliction, and we’re talking about people who will not be running the Admin UI module.

(Eventually there will be a situation where people are running a future version of the Reference Application based on Platform 2.x, and the Admin UI module will be providing their admin screens so that they don’t need the Legacy UI module.)

My comment was about this general topic and not directed at any specific comment.

Being familiar with both adminui and legacyui, it seemed to me that the plan was to remove admin features from the platform into a module, legacyui, so those features could be eventually provided by adminui.

The point I was making really was if the plan was to support admin features in adminui in the future, maybe it was not worth expending too much effort on legacyui.

1 Like