- Java page controllers in org.openmrs.module.yourmoduleid.page.controller
- Groovy page views in your omod's web/module/pages
- Java fragment controllers in org.openmrs.module.yourmoduleid.fragment.controller
- Groovy fragment views in your omod's web/module/fragments
Folders and Packages
In the 99% case where you're using this standard configuration, you should create the folders:
The UI Framework supports a "development mode" that helps you iterate rapidly on web-layer functionality, by automatically recompiling controllers as you edit them, and automatically reloading views. Note that development mode only automatically recompiles controllers (for pages or fragments), not other classes. But you should be iterating on your module's domain objects and service layer using the unit testing framework anyway. :-)
To enable development mode for a particular module, you need to set an argument at runtime before starting up OpenMRS.
The primary means for doing this has been to set a VM argument on the JRE you are running OpenMRS in. (In Eclipse you can do this from the JRE tab of your jetty:run Run Configuration.See section on Setting a VM argument below)
If you set the following VM argument, it will be picked up by the view and controller providers configured by the StandardModuleUiConfiguration bean for yourmoduleid.
The VM argument, above, can be provided in Netbeans As of version 3.3 of the uiframework module, there some alternative options available for configuring development mode:
- You can now specify any of the runtime arguments via either VM arguments (as described above), or as properties in your OpenMRS runtime properties file
- You can continue to specify each individual module that you wish to put into development mode by listing it and the path to the code for it explicitly as described above
- For developers who want to more easily enable development mode for several modules that are checked out into a common location on the filesystem, you can specify
This will work only if you have your code checked out into a directory named either <moduleId> or openmrs-module-<moduleId>
As an example, lets say that I manage all of my OpenMRS code in a single directory: /home/openmrs/code
Then, within that directory I have various modules cloned that I work on:
If I set the following in my openmrs-runtime.properties file:
Then starting up my system, if any modules with moduleId in coreapps, reportingui, htmlformentryui, or appointmentschedulingui are started, then development mode will be enabled for these.
However, if at the moment I am only working on coreapps and reportingui, and so I only want to enable development mode for these, then I can further limit this with the following in my openmrs-runtime.properties file:
This will also work as if my code is checked out under simply the moduleId (i.e. /home/openmrs/code/coreapps)
Setting a VM argument
- In Eclipse you can do this from the JRE tab of your jetty:run Run Configuration. In Eclipse, you need to specify this as: -DuiFramework...
- In Netbeans you can do this by adding it to the jetty:run custom goal. In detail, download/open the OpenMRS core source in Netbeans, then open the openmrs-webapps subproject. Right click on the webapps subproject, select Custom/Goals... This will bring up the Run Maven popup. Type jetty:run in the Goals and the VM argument line in the Properties text area of the goal by typing the following: uiFramework.development.yourmoduleid=/path/to/root/of/mavenized/yourmoduleid
- (Note, in Netbeans you should not include "-D", nor the quotes around the path.
Note, -D should be included, but not the quotes in the eclipse environment.
Note that development mode only automatically recompiles controllers (for pages or fragments), not other classes. But you should be iterating on your module's domain objects and service layer using the unit testing framework anyway. :-)
Troubleshooting: It is reported that in unix you may need to delete " from the path and escape whitespaces with \ if any.