# Design
## Component Architecture
Each FHIR form component instance should follow a predefined hierarchical skeleton, by which itself will have the capability for repeating and grouping in desirable cardinality.

![High level design diagram](fhirformhighleveldesign.jpg "Diagram 1")

### CustomElement
`CustomElement` is the base class for all input components. Also, `RepeatableComponent` and `GroupComponents` are inherited from `CustomElement`.

### Repeatable Component
This is a container component, which is inherited from `CustomElement`. As its name suggests, its content can be replicated multiple times it makes itself siblings with each other. Also, it is limited to only contain a group component. Hence, the group component, of the same content, can be repeated as many times as needed.

It should have an attribute called `repeats`. The default value of `repeats` should be `false`. Implies there will be only a single instance of group component as its child. If the `repeats` turns `true` then, it can have as many replicas of the group component as the input resource demands. Also, an action button will appear on the premise of the repeatable component, which lets the user click on it for adding a new replica of the group component.

### Group Component
This is another container component that simply groups its children. Even though it can composite multiple kinds of components, each of its children have their independent existence with its attributes, values, validations, and events, etc. However, the creation, allocation, deallocation, and destruction of its children are controlled together by itself.

The group component should be able to contain any implementations from `CustomElement`. In short, it can contain a repeatable component, a group component, or any other input component altogether.

### Input Component
It's a simple component that has a provision to accept some kind of input from the user.

## FHIR FORM
This is a container component that wraps one or more repeatable components.

![FHIR Form logical layout](fhirform.png "Diagram 2")

It finalizes an FHIR Questionnaire interaction from the user. Hence, it should have various mechanisms to interact with the DOM of the containing web page. The interface of an FHIR FORM is designed as given below.

### Attributes
!Name|Type|Description|Default
|--|--|--|--|
|`resource`|string,object|An FHIR questionnaire resource. Either in string format or as an object. This is the questionnaire resource for which the form has to be rendered.|empty string
|`have-reset`|boolean|Determines to hide or show a reset button for the form|true
|`have-cancel`|boolean|Determines to hide or show a cancel button for the form|true
|`submit-text`|string|Caption for the submit button|"SUBMIT"

### Events
**changed**

`function (jsonPath, oldValue, newValue, response)`

This event is raised whenever the value of an item in the questionnaire is successfully changed. The call back of the event can have four parameters. The parameter `jsonPath` should specify the path of the item that changed in the expected response resource, `oldValue` should specify the value of the item before it last change, `newValue` should specify the latest value of the item and `response` should specify latest draft form os the response resource with all latest available values.

**error**

`function (jsonPath, message, e)`

The event is raised whenever any of the items in the questionnaire is failed on its validation. The call back of the event can have three parameters. The parameter `jsonPath` should specify the path of the item that changed in the expected response resource, `message` should specify the error message returned from the validation, `e` should specify a javascript error object if available, otherwise null.

**canceled**

`function ()`

This event is raised whenever the user clicks on the cancel button on the FHIR FORM. Once this event is received in the parent application, it is expected to release all allocations associated with the FHIR FORM in the application. The FHIR FORM is expected to clear its own resource prior to raising this event.

**submitted**

`function (reponse)`

This event is raised whenever the user clicks on the submit button and all input components return a valid input. The call-back event will have the questionnaire response as its parameter. Once this event is received in the parent application, it is expected to release all allocations associated with the FHIR FORM in the application. The parent application can use the questionnaire response for the purpose of serving its own business. The FHIR FORM is expected to clear its own resource prior to raising this event except for the questionnaire response.

If the user clicks on the submit button and any of the input fails its validation then an error event should have occurred.