Los POJOs Survey
- 1 Code
- 2 The team
- 3 Requirements
- 4 Milestones
- 5 Individual tasks
- 6 Suggested improvements to Web API
- 7 Screenshots
All code is hosted on GitHub: Our repo
- Marianne Grov (Git user: mgr090)
- Øyvind Raasholm Tangen (Git user: oyvindrt)
- Kristian Johannessen (Git user: kjohann)
- Torkil Aamodt (Git user: tork)
- Knockout: Knockout homepage
- Bootstrap: Official Bootstrap page
- JQuery: JQuery homepage
- Formee Formee homepage
- Featherlight Featherlight on GitHub
- GitHub Our repo again
- Trello Our Trello Board
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.
- 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
- 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
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
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.
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.
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.