### Forms and Controls:
"The system then calculates and displays the variance from the target. The system highlights
the variance in red when it is 10% or more below the target, or in green when 5% or more above the target."

- two main responsibilities:
	- Screen layout: defining the arrangement of the controls on the screen, together with their hierarchic structure with one other.
	- Form logic: behavior that cannot be easily programmed into the controls themselves.

- copies data of data:
	- record set(DB)
	- session state
	- screen(view) data

- Data binding(direct data - form control binding):
	- to help session data and screen data synced;
	- to avoid infinite loop of updates define data flow direction;

- Data binding could be tricky, when some complex logic of view is involved.

Example: Variance field(reading field) which is result of difference calculation of two actual field.
In general data binding gets tricky because if you have to avoid cycles where a change to the control,
changes the record set, which updates the control, which updates the record set....

*The flow of usage helps avoid these*
- we load from the session state to the screen when the screen is opened,
- after that any changes to the screen state propagate back to the session state.

It's unusual for the session state to be updated directly once the screen is up.
As a result data binding might not be entirely bi-directional - just confined
to initial upload and then propagating changes from the controls to the
session state.

Solutions: Events(Observer pattern), form fields subscribes to events. On input 'input_variance' is
triggered. Form gets event, calculates difference and send data back to variance field.

### MVC

The idea behind *Separated Presentation*: This pattern is a form of layering, where we keep
presentation code and domain code in separate layers with the domain code unaware of presentation code.
Domain objects should be completely self contained and work without reference to the presentation,
they should also be able to support multiple presentations, possibly simultaneously.

In MVC, the domain element is referred to as the model. Model objects are completely ignorant of the UI.

The presentation part of MVC is made of the two remaining elements: view and controller.
The controller's job is to take the user's input and figure out what to do with it.

At this point I should stress that there's not just one view and controller, you have a
view-controller pair for each element of the screen, each of the controls and the screen
as a whole. So the first part of reacting to the user's input is the various controllers
collaborating to see who got edited.

https://martinfowler.com/eaaDev/uiArchs/mvc-deps.gif

There would be an assessment view that would represent the whole screen and define the layout
of the lower level controls, in that sense similar to a form in Forms and Controllers.
Unlike the form, however, MVC has no event handlers on the assessment controller for
the lower level components.