As part of the 2.0 release of the platform, we intend to move the legacy UI to a module, these efforts were started this past summer as part of GSoC, and Tharunya did a great job in setting the ball rolling. We’ve put together a sprint and we are calling on all you developers to help us get this done. Below are the details about the sprint:
We also put together a wiki page to guide you on how to move things around which you can find here
If a ticket has a dependency on another ticket, you can find this under the ‘Issue Links’ section on a ticket, make sure you pick it only if the other ticket is complete.
Thanks. I see about 4 days ago you removed all of the controller mappings on master, so parts of the legacy UI that have not yet been ported to legacyui are broken. I somewhat expected that each controller / code / test / jsp / asset would be refactored individually into the legacyui module, so that nothing would break during the transition. I guess that’s not the plan…?
So which assets have already been removed from core en-masse and which assets still need to be removed by legacyui implementors? (java classes, tests, jsps, other related assets?)
We have an ongoing sprint to copy the UI in the legacyui module.
We do not expect anyone using the old UI from the platform as per the
master branch. So if you find that you need to do so, feel free to tell us
why. Could it be that you are fixing a ui bug from the platform instead of
doing it from the legacyui module? Or is it just something else that we
need to know?
For now, we have removed jsps, controllers and their tests. We are yet to
move other ui related things. We do not have a full inventory of it all,
but we shall see it as we move along.
The sprint dashboard is at
https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=83
Thanks. I was considering helping out with the legacyui module, so I wanted to understand the process. I’m also not very familiar with much of the UI, so I thought having a running copy of it would be a good reference while porting functionality over. I suppose I could run a previous branch.
Any tips would be appreciated - can you point me toward the best way to rapidly redeploy legacyui after making changes?
As for rapidly redeploying, i use the FileSync eclipse plugin to automatically deploy changes in my development jsps immediately on each save.
For the controller and other java classes, i use these VM arguments:
-javaagent:/Projects/springloaded-1.2.4.RELEASE.jar -noverify -Dspringloaded=inclusions=org.openmrs…* -Dlegacyui.development.directory=/Projects/openmrs/legacyui
Do not forget to replace the above file directories with yours.
With the above, as long as am not making changes in webModuleApplicationContext.xml, i deploy the module once for the first time. For the rest of the changes, they are auto loaded on save.
I have just reviewed, tested and merged your pull request. That was fast
and great. You deserve a special badge for being the first volunteer to
complete a ticket on this sprint!!!
While working on this, is there anything that you felt we should do to make
working on these tickets even easier?
Such feedback will help us improve the process and hence encourage even
more volunteers to join the sprint.
Thanks. I have some ideas that could potentially save a lot of manual work (ViewResolver tricks, using configurations instead of annotated classes for static pages), but I’m not sure I want to rock the boat given that there is an established procedure that’s already been documented.
docs refer to copying the jsp over and then deleting it from the platform. From what I’ve seen, the jsps are already pretty much all removed from the platform, and already copied over to legacyui (which was a big help)
Some of the comments under annotated controllers part a) about appending ‘module/legacyui’ to viewnames also apply to XML-configured controllers. At first I did not realize some XML configured controllers had viewnames embedded in them, which caused things to not work. (however there are very good debugging messages showing up when viewnames are not found, generally searching for those viewnames in legacyui will find the problem). Maybe the documentation could be updated to reflect the need to update both types of controllers
The controller section also refers to copying controllers over from core, but many controllers have been deleted from the platform, so that should be updated. Your comment about finding old code from https://github.com/openmrs/openmrs-core/tree/75fa95ea31ce64fbe68ad55b7aacd6bb23af84be was SUPER IMPORTANT. I cloned a copy of that tree locally to make copying code over easier. I think that info should be in the body of the document
Your comment about using devtest02 as a baseline could be added to documentation
I haven’t tried out the comments you made about making quick changes to modules but I found out that using the module admin page to update the module works well, since that page has already been ported to legacyui
for newcomers to openmrs, since core no longer has a homepage with links on it, it’s pretty important to know where to find the legacy admin homepage at http://localhost:8080/openmrs/admin/index.htm
Hi Kristopher, thanks for the feed back, yes some things have already been removed from the platform and i think there is a message on that wiki page that says that some things might already been moved.
I’m getting test errors on ObsFormControllerTest which was just recently checked in.
This raises 2 main questions:
Is the Legacy UI module in CI? I don’t see it listed at ci.openmrs.org. I suggest that if it is not, that we get it set up soon. It’s nice to be able to doublecheck CI to see if the problem I’m encountering is just me or an overall build problem
What is the best forum to discuss technical questions regarding LegacyUI? Just keep responding to this thread, or open up other threads in Talk, or are there other places that Sprint team members communicate?
Basing on the experience you already have in doing these tickets, you should go ahead and add anything you feel missing or needs to be changed in the documentation.
