Container/presenter architecture was put in place to ensure the best re-usability/sharing
- form created in presenter - it's the presenter which decides how the data is displayed
- container needs only the value and errors propagated from the presenter
- container can set the default value
- presenter implements ControlValueAccessor and Validator (or AsyncValidator) interfaces
- propagate the value, the form status and the errors
- container apply FormControlDirective on the presenter html tag
- container set the default value using formControl directive
- listen to the value and status changes using the same directive
See FORM_STRUCTURE
- interfaces for the error messages provided in @o3r/forms
- the error messages returned by validators are used in the inline error display
- simple/basic/primitive validators - set as a configuration of the presenter
- localization of the error messages associated done on the presenter
- the error object associated is computed here and has to be compliant with the store object model
- getFlatControlErrors function is available in @o3r/forms to help with the creation of error object model
- custom validators created at container level
- localization of the error messages associated done at container level
- custom validators are passed as an input to the presenter
- the error returned by the validator has to be compliant with the form error store model
- a dedicated FormErrorStore is available on @o3r/forms
- allow the display of errors anywhere on the page
- the error object model contains the translation key and params
See FORM_VALIDATION and FORM_ERRORS
- submit triggered by the submit button in the presenter and an event is emitted
- container capture the event and execute the submit form logic
The answer for this question is that we should avoid having multiple form tags in the same page, as much as possible, because it adds a lot of complexity. We should try to have only one form tag that encapsulates everything and one submit action.
If the case of multiple forms it's really needed, then we found the following solution:
- submit button hidden on the presenters
- the submit is triggered from the page
- an observable to trigger the submit is passed as input to the containers;
- AsyncInput decorator is provided in @o3r/forms to be applied on the observable input to ensure performance
- submit form logic is executed on the containers
- containers emit events when the submit is done
- the page (parent) capture the events and continue its logic
This can be applied also, with only one form on the page, when you don't want a submit button in the presenter.
At the first display of the form, the inline errors (if the form is invalid) are not displayed, because the form element is not touched and dirty
In the case you want to show the inline errors after the submit, you have to:
- register a function in the container to mark touched and dirty the form
- the function is passed via an @Output from the presenter and has to be called before executing the submit logic
- markAllControlsDirtyAndTouched helper is available in @o3r/forms to mark interactions on given form