Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

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

Documentation

Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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
  • Do not return retired metadata or voided data by default – ~bmamlin
    • In API 1.x, metadata lists – e.g., getConceptAnswers() – include retired values by default, which can encourage use of values that are no longer valid.
  • More use of final keyword for parameters – ~bmamlin
  • Attention to multithreading support – ~bmamlin
  • Use Long instead of Integer for internal identifiers -- ~bmamlin
    • Part of our goal for supporting 2+ million patients in OpenMRS will require supporting tables that contain over 2 billion rows
  • Use absolute times (i.e., UTC) everywhere within the API.
    • We can always provide convenient means for timestamps to be rendered in the current timezone; however, all stored values should be in UTC in order to eliminate issues with transferring data across timezones or implementation headaches in locations that observe DST.
  • Introduce an Event Bus so not everything is done via AOP
  • 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
  • Clustering should be supported at the API level, this will be helpful as some implementations grow bigger and wish to run in clustered environments - Wyclif Luyima
  • I would rather us to have a lot of methods with less parameters than one method with tons of parameters. (so we won't see a call getPerson(null, null, null, null, null) in our code) – Nyoman Ribeka
  • Integration of a full text search engine and at least replace the existing ConceptWord engine - Wyclif Luyima
  • To add on Win's request, we should have less methods too, we can replace some method parmaters with a single map of optional parameters, i believe there can be other use cases for this – Wyclif Luyima
    • INSTEAD OF THIS:
      Code Block
      ConceptServce.getConcepts(String phrase, Locale locale, Datatype includeDatatype, Datatype excludeDatatype, ConceptClass includeClass, .... );
    • WE HAVE THIS?:
      • Method signature: The methods method declares the optional arguments via an @optionalParam annotation
        Code Block
        @OptionalParam(name='locale', type=Locale.class)
        @OptionalParam(name="includeDatatype", type=Datatype.class)
        @.......
        public List<Concepts> getConcepts(String phrase, Map<String, Object> optionalParams){ //you can have a reasonableminimal setnumber of required parameters for the method
            Locale locale = null;
            Datatype includeDatatype = null;
            .....
            if(optionalParams != null)
                 locale = ParamUtils.getParameter(optionalParams, 'locale', Locale.class);  // This will be a generic method in a utility Class ParamUtils
                 includeDatatype = ParamUtils.getParameter(optionalParams, 'includeDatatype', Datatype.class);
                 .......
               }
               dao.getConcepts(phrase, locale, includeDatatype, ..............)
        }
        
      • Calling the method
        Code Block
        Map optional parameters = new HashMap();
        parameters.put('locale', Locale.ENGLISH); // or something like Context.addAttributes(attributeNameValueMap);
        parameters.put('datatype', Context.getConceptService().getDatatype(1));
        List<Concept> concepts = Context.getConceptService().getConcepts('malaria', parameters);
  •