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
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.
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
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.
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.
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.
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?
@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.
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.