Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Documentation

Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The OpenMRS 2.0 UI is undergoing a lot of improvement and the API should garner an equal amount of attention.

There is a possibility of turning the current api into a jar or omod file.  This creates space for the API to be completely rewritten without having to deal with backwards compatibility

Package Name Options

If the pojos and services are going to be changing drastically, then the package for the 2.0 api will have to be different.  Keep in mind that the current package name is org.openmrs.api

Pojo Change Wishlist

The objects in the api (Patient, Person, Obs, etc) follow a common theme.  Here is a list of things that I've either dreamed up or heard from others about things to change in them

  • Make the objects more DTO-like (less hibernate magic) - Ben Wolfe
  • Remove all calls to the database in pojos (no calls to Context) - Ben Wolfe
  • Remove ability to traverse entire graph (creator object attribute becomes creatorId integer attribute) - Ben Wolfe
  • Never use Sets as the Collection implementation as an attribute on an object (use List) - Ben Wolfe
  • Most properties immutable – ~bmamlin 
  • Avoid empty constructors & don't allow invalid objects to be created: if "stubs" needed, make them explicit (i.e., a separate object) – ~bmamlin 
  • Use uuids for .equals and .hashcode - ?Ben Wolfe (see TRUNK-1993)

Service Change Wishlist

Similar to the previous list, here is a list of things that people would like to change about our current services (PersonService, PatientService, etc)

  • Lessen the hibernate 'magic'.  Never return a hibernate magical object - Ben Wolfe
  • Get rid of the need for sessions (opensession/closesession).  This goes with previous point about hibernate magical objects. - Ben Wolfe
  • Get rid of the static Context.  Inject everything like standard spring apps in order to take advantage of other tools, mocks in unit tests, etc - Ben Wolfe
  • More use of final keyword for parameters – ~bmamlin
  • Attention to multithreading support – ~bmamlin
  • Follow lessons given byBloch's Google Tech Talk (slides) – ~bmamlin 
    • Don't let implementation details "leak" into API
    • Self-Explanatory, Consistency, Symmetry
    • Strong javadocs
    • Avoid long parameter lists (break up method or create helper class to hold parameters)
    • Avoid return values that demand exception processing (return zero-length array or empty value, not null)
    • Favor unchecked exceptions
  • No labels