Los POJOs Survey

From mn/ifi/inf5750
Jump to: navigation, search

Code

All code is hosted on GitHub: Our repo

LosPOJOs.png

The team

  • Marianne Grov (Git user: mgr090)
  • Øyvind Raasholm Tangen (Git user: oyvindrt)
  • Kristian Johannessen (Git user: kjohann)
  • Torkil Aamodt (Git user: tork)

Requirements

Technologies

Mandatory requirements

From the lecture slides

  • Single event data entry form.
  • Skip logic (eg. If pregnant, fill in these extra forms).
  • Make interface for easily defining form and skip logic (integrated with single event, but you’ll need some additional info).
  • Available as DHIS2 web app (and Android app (phonegap)).
  • Touch friendly UI.

Our own

  • The app should able to get form by input id from user.
  • The app should have a separate admin gui for specifying skip logic.
  • The skip logic will be stored in "System settings" on dhis2 with a key comprising of LosPOJOs + formId.
  • Try to minimize amout of requests to API

Optional requirements

  • The app should able to navigate a list of forms, where the app will get forms from /api/programStages.
  • The app should have a gui where a superuser can specify user roles that has access to specifying skip logic.
    • user roles will be stored using "System settings" with key LosPOJOs

Milestones

Milestone 1: 1st November

  • Document features and architecture on Wiki
  • Show understanding of DHIS2 web apps

Milestone 2: 15th November

  • First bare-bone version - static HTML
  • Uploadable as DHIS2 web app

Milestone 3: 30th November

  • Finished, if applicable also with mobile app.
  • Final delivery: 8th December
  • Presentation: 9th December

Individual tasks

See Trello: Los POJOs on Trello

Suggested improvements to Web API

Reduce number of requests needed to use API

The API as it is now is maybe a little to modular. Sometimes it is good to get as little info as possible in each requests, but in our use-case, a little more would have been nice. To actually show a complete form, we have the following flow:

  • First a request is done to get the programs, but in the response here, we only get the IDs of the programs and no info what so ever about programStages.
  • So to get the programStages of a selected program one needs one request to get the program itself, then one request for each of the programStages. But again, information is lacking.
  • After a programStage is selected, one therefore has to get each dataElement. But these contain only IDs to the related optionSets, which leads to even more requests.

It would be preferable in a case like ours, to have an option that would give all data in one or maybe two requests.

Same data in HTML representation of API as in the other formats

For some elements, the HTML representation (which is typicall what developers look at when browsing an API) has less info than the other representations like JSON and XML. This made us believe for quite some time that there was no link between dataElements and optionSets, as this is not shown in the HTML.

Ugly JSON

The JSON representation needs a lot of cleaning up. Right now it looks like you have translated directly from XML, which leads to a lot of repeated data.

Orgunits related to programs

As it is now, each program has all orgUnits related to it in the API. This is a bit odd, as this is not how it works within DHIS. This also leads to a lot of overhead within applications using this feature, which is what we have done.

Screenshots

Full.png

Half.png

Small.png

Small with short program.png