Update on moving legacy UI to a module


As some of you might already know, efforts have been going on to move the legacy UI to a module, the initial work was done by Tharunya this past summer as part of GSoC 2015, in the past couple of days i have been spiking on moving more components into the legacy UI module and in general assess the status of things, several jsps have already been moved and seem to be working as expected. Correct me if am wrong but i think the following things will stay in core:

  • The installation and update wizard just because i think it is logical to do so.
  • Home page and possibly the login page
  • Nearly everything that is defined in web.xml should stay in core i.e context loaders, listeners servlets, filters, tag libraries etc because we can’t wire them into the webapp from modules after the servlet context is built. I think some filters and servlets can be moved but some might get blocked by TRUNK-4673
  • Some beans in openmrs-servlet.xml like some resolvers, themeResolver, interceptors, json/xml marshallers because the rest module uses them and i think they need to be reused by other modules.

Below are some quick to do items:

  • Move the legacyui branch to the openmrs space in github
  • Remove some unnecessary files generated by module archetype e.e extension and point, service, dao and tests

Of course the tickets in the legacy UI module’s jira project need to be addressed, may be in a sprint

Some key questions that come to mind:

  • Are we moving the header and footer?
  • Are we moving all images, CSS and JS to the module? Except for the ones to be used for the pages that will remain in the platform
1 Like

I would approach this from the baseline that everything moves to the module unless there is some reason that it can’t. The goal is that “OpenMRS Platform 2.0” has no UI at all, and out of the box you can only interact with it via web services. And you can either add the Legacy UI module, or build your own UI on top of it, unencumbered by anything leftover from the legacy UI.

  • I agree that the installation and update pages stay in openmrs-core, because you need to be able to bootstrap in the first place.
  • JSON/XML marshallers stay in openmrs-core to support REST
  • The homepage and the login page should move to the module.
  • tlds and tag files should move to the module
  • all filters and servlets should generally move to the module
  • interceptors should generally move to the module
  • resolvers should move to the module
  • header and footer move to the module
  • CSS and JS move to the module

I realize that some things may be hard to move because the module framework doesn’t allow you to load them. I suggest that we try to add support in the core module framework to move these. (It may be that we aren’t able to move everything before our release deadline, but let’s at least try to, and made the decision not to move them only if we’re forced into it.)

So far i haven’t yet figured a way to add tag libraries and error pages entries dynamically to a web application. If there is no home page, when one is done installing OpenMRS, what page do we take them to? Do we leave them on some strange velocity generated page within the installation wizard, i still believe we will need some form of home page in core that may be just says, “OpenMRS is running”, it doesn’t have to be the same home page as before.

Good point. We do need some sort of static home page as a fallback.

I did some googling and didn’t find much help. Have you tried asking in a Java IRC room?

As long as we are including a web-based installer, it can have a “done” page. We shouldn’t need a home page for a platform that doesn’t contain a web app. In other words, the “installation completed” page can be part of the installation process. If we ever move the installation process (e.g., to a non-web format), that page would go with it.

Update: btw, forgot to mention… I agree with all of @darius’ points above about moving everything that isn’t necessary for serving REST responses out of the platform.

As a concession to practicality, I think we should have a static “200 OK - OpenMRS is running” page. Yes, in theory you could check this via REST, but it would be nice if someone can go to (url)/index.htm in a browser and see this one bit of information.

The platform is going to be a war file and if one goes to the context root, do you mean the request should fail? I wouldn’t agree with that, i think we need a single page that just gives a status message that OpenMRS is running just like tomcat does when you go to localhost:8080, i don’t mean we need a jsp for a home page as such, it could be just the default velocity generated page the install wizard takes you to if it is already done, my point i guess is one should see something when they go to the context root


I likewise think such a static page is necessary: as a user; not only after running the installation process but often times i may want to run the platform (war file + rest webservice module) and then use an external application such as https://www.getpostman.com/ or just a normal browser to interact with openmrs using rest. And so such a page would be informative to me about the openmrs state

If it’s a WAR then by definition it’s a webapp right?


I had the same thought as Lluis. I’m totally on board with a minimal webapp, but I personally would love to see us invest in a useful, single page that can provide information similar (though maybe prettier) to what we have at: admin/maintenance/systemInfo.htm - basically sufficient information to confirm at a glance that the environment is set up and running as you intended it to be.

1 Like

Mike, that seems to sound like a good idea but the challenge is those details are only visible to authorized people, it would mean we would need to a login page so that one first authenticates to view the system info yet at the same time we are trying to get rid of the login page.

Seems like i have figured how to move the custom tags, i doubt if it will be possible for error pages but i think we can ignore those. By the way, in servlet API 3.0 there are ways that were introduced to register servlets, filters and listeners programmatically, the module engine should adopt these soon to replace the hacky ModuleServlet and ModuleFilter classes.

1 Like

How about a small utility module that can be optionally installed for such things like system information?

We need start preparing ourselves and merge the work Tharunya did over the summer into master ASAP, this means there should be no more fixes to things we are moving to the module otherwise we will end up with several painful merge conflicts. The tickets to address issues in the old UI need to be moved to the legacy UI module’s jira project and possibly have all pull requests for these tickets merged soon but still this will cause conflicts anyways.

@wyclif, it makes sense that we need to do the merge ASAP; but I don’t understand the implication of that for most people’s work. Can you clarify what people should do because of this?

The more developers work on tickets that involve editing the same files we are moving, the more merge conflicts we will encounter when merging the legacyui branch into master, typically this happens when updating the branch with changes from master before merging it into master. With git, in most cases if 2 or more branches happen to have changes in the same file, merge conflicts will arise.

I understand how merges and conflicts work.

What I’m asking is, who is this message for and what actions should they take?

E.g. you said “We need start preparing ourselves and merge the work”; I presume that you are going to lead that up and I don’t need to think about it anymore until you say otherwise. Is that right? Or are you suggesting someone else should merge the branch, or help you do it?

Are there people working on Legacy UI tickets now, and you want them to pause?

1 Like

@wyclif can correct me if I’m wrong, but I believe there’s a pull request from @tharunya with the initial migration of several features to the Legacy UI module (presumably, it would be mostly deleting things from core). Any edits to those pieces (user & patient admin?) in core will cause conflicts.

Based on what I understood from @tharunya, if we have any CI builds for the ref app (i.e., expecting the legacy UI) that use master openmrs-core (Platform 2.0), we’ll want to ensure they include the Legacy UI module (no harm if the Legacy UI module is installed before legacy UI is removed from core). Then we can merge her pull request. From that point, working through the remaining LUI tickets (transfering legacy UI to the module) should be done piece by piece in openmrs-core/master to avoid merge conflicts.

So, I think Wyclif is saying "nobody should be touching the user & patient admin functions in openmrs-core; rather, any changes to those should be done in the Legacy UI module.

1 Like

Thanks Burke, that’s more like what i meant, however i see no pull request with Tharunya’s initial work.

@Darius i’m writing this generally to developers working on core tickets, also the community dev swim lane lead should be merging any tickets that have legacy UI changes to be merged ASAP because if we merge Tharunya’s work then those pull requests will be ‘bad’. And we should avoid having any similar ones, those fixes should belong to the legacy UI module, the challenge gets worse if such a pull request or ticket involves changes both in the API and UI.

Regarding including a landing page (i.e., static web page), I think there’s consensus that, as long as we’re delivering the platform as a web application (WAR), it makes sense to have a web page indicating the application is running.

Since this will be anonymously viewable and modules can provide status pages, I would suggest a simple, static, “OpenMRS Platform is running” text page at the root.

1 Like