Difference between revisions of "MFL"

From mn/ifi/inf5750
Jump to: navigation, search
(Updated client architecture section.)
m (Moved the architecture illustration.)
Line 51: Line 51:
  
 
=== Client architecture ===
 
=== Client architecture ===
 +
[[File:Client architecture.png|thumb|538x538px|The client architecture of MFL]]
 
The client is developed as a Single-Page Application (SPA) using Facebook's React view framework and the Redux/Flux architecture.
 
The client is developed as a Single-Page Application (SPA) using Facebook's React view framework and the Redux/Flux architecture.
[[File:Client architecture.png|thumb|538x538px|The client architecture of MFL]]
+
 
 
At its core is a '''normalized Redux store''' that serves as a single source of truth for the application state. This state is only changed by emitting actions (objects describing what happened). When actions involves API interactions, they will wait for a response before dispatching the relevant action(s).
 
At its core is a '''normalized Redux store''' that serves as a single source of truth for the application state. This state is only changed by emitting actions (objects describing what happened). When actions involves API interactions, they will wait for a response before dispatching the relevant action(s).
  

Revision as of 01:05, 6 December 2017

Group members

Aanund Nordskog (aanundjn@ifi.uio.no)

Nicole Keppler (nicoleke@student.matnat.uio.no)

Saliha Sajid (salihasa@student.matnat.uio.no)

Henrik Halvorsen Hortemo (henrihho@ifi.uio.no)

Product description

MFL is a DHIS2 application for searching, browsing and proposing changes to organisation units, as requested by the Master Facility List assignment.

User stories

Our understanding of the assignment is reflected by the following user stories:

  • As a user I want to find specific organization units
    • As a user I want to search for organization units by name
    • As a user I want to filter my search results by unit group membership
    • As a user I want to filter my search results by ancestor relationships
    • As a user I want to filter my search results by which data sets are assigned to the organization units
  • As a user I want to see detailed information on a particular organization unit
    • As a user I want to see all attributes of a particular organization unit
    • As a user I want to see the location of a particular organization unit
    • As a user I want to see which organization unit groups a particular organization belongs to
    • As a user I want to see what data sets are assigned to a particular facility
    • As a user I want to see data element and/or indicator values for the particular organisation unit for the current/last year
  • As an administrator I want to select what data elements and/or indicators to display
  • As a user I want to propose changes to organization units
    • As a user I want to propose changes to organization unit attributes
    • As an administrator I want to review submitted proposals
    • As an administrator I want to mark proposals as resolved/invalid

Mockups

Our UX approach is reflected by the following mockups:

MFL on Moqups.com

Screenshots

The application currently looks like this:

[Browser]

[Detail]

[Admin]

Architecture

MFL is designed as a client/server application where the DHIS2 server is responsible for data storage and data access logic, whereas the client is responsible for application logic and presentation logic.

Client architecture

The client architecture of MFL

The client is developed as a Single-Page Application (SPA) using Facebook's React view framework and the Redux/Flux architecture.

At its core is a normalized Redux store that serves as a single source of truth for the application state. This state is only changed by emitting actions (objects describing what happened). When actions involves API interactions, they will wait for a response before dispatching the relevant action(s).

The normalization of data in the Redux store greatly simplifies handling of the nested JSON objects returned from the DHIS2 API, as it avoid data duplication and allows different parts of the app to easily reuse data fetched by other parts.

Using React, the view part of the app has a component-based architecture. In MFL, these are divided between connected componentsa(containers)nd presentational components.

The connected components are focused on how things work; they subscribe to the Redux state through its selector functions, dispatch Redux actions and pass relevant data and callback functions as props to (one or more) child components. The container components maps more or less to the different screens of the application.

The presentational components are concerned with how things look (markup and style). They are not aware of Redux, but read data and callback functions solely from passed props. This makes them reusable in different context.

This separation of concern makes the application easy to reason about and makes it easy for contributors to work on different parts of the app simultaneously.

Timeline for development

Week 44

  • Finalize product requirements
  • Create mockups
  • Setup application foundation (inside DHIS)

Week 45

  • Static version of the application:
    • Search view
    • Detailed view
  • Document relevant API queries

Week 46

  • Static version of the application:
    • Edit view
    • Admin view
  • Dynamic version of the application:
    • Search view
    • Detailed view

Week 47

  • Dynamic version of the application:
    • Edit view
    • Admin view

Week 48

  • Buffer and Testing
  • 1.12.2017: End of project

Licensing

Division of labour

  • Aanund Nordskog
    • Search results, admin view, queries
  • Nicole Keppler (nicoleke@student.matnat.uio.no)
    • Detail view of organisation unit
  • Saliha Sajid (salihasa@student.matnat.uio.no)
    • Sidebar and Filtering
  • Henrik Halvorsen Hortemo (henrihho@ifi.uio.no)
    • Redux and request queries, admin view

External links

MFL on GitHub

MFL on Moqups.com