Workshop 23.05.2018
The recordings of the workshop are available at the file server:
Related repos:
Project with UI framework extensions and reference content app implementation: https://git.magnolia-cms.com/users/apchelintcev/repos/content-app-poc/browse
...
Jira |
---|
server | Magnolia - Issue tracker |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 500b06a6-e204-3125-b989-2d75b973d05f |
---|
key | DEV-910 |
---|
|
Jira |
---|
server | Magnolia - Issue tracker |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 500b06a6-e204-3125-b989-2d75b973d05f |
---|
key | DEV-947 |
---|
|
Main goals
- Adapt UI framework to Vaadin 8 concepts
- Data binding in forms, dialogs and grids - simplify the existing solution
...
Model View Presenter
Related Initial investigation concept: Design patterns in UI content app
Reasons to bother | What changes | Benefits |
---|
- Way too many interfaces where a mere class would do (see IoC part as well)
- The way we used it before is cumbersome and not too beneficial.
- Concept of Model is not well defined.
- Poor component isolation patterns
- views know about sub-views, presenters know about sub-presenters [...and sub-views].
- poor state management (the parent views/presenters may just have most of the child view's state/business logic).
| - We try to prefer classes over the interfaces. If we introduce interfaces, we try to keep them small and function-oriented.
- Instead of MVP we use something like MVVMP (Model-View-ViewModel-Presenter)
- Model is the good ol' datasource like JCR workspace.
- View is now the entry point and the driver of the pattern. Views may compose and even interact with each other (though we we should not encourage that!)
- ViewModel is the state of the View (all the properties that define the view in real time)
- Presenter - optional, completely isolated part which is used to help View interact with Model/ViewModel
- We implement the ViewModel part via so called
ViewContexts - interfaces that describe a certain part of mutable state (selection, value, location etc).- We provide the views with the ability to bind contexts and share them with the sub-views (see more in the IoC section).
- For the ease of use, we do not enforce the developer to actually implement the interfaces, we generate them. We use some reactive technology for convenient subscription.
| - Views are more component-like and are easier to compose.
- Interfaces/classes do not expose methods like
#refresh() , that encourage external control over the view. - All the internal view state management happens in the view itself (no case when sub-app reacts on events and updates the state of the sub-views/components).
- All the necessary context can be injected via
ViewContexts
- Some synergy with how client-side frameworks manage the UI's (Redux/React contexts do similar things though in more conventional way)
- Less code to write (less noisy listener interfaces, less abstractions)
|
As an example of benefits we get after applying the new concepts, let's take a look at the class diagram of the Browser sub-app before and after.
Before
Image Removed
After
...
Image Removed
Inversion of control (IoC) capabilities in UI
...
Reasons to bother | What changes | Outcome |
---|
- Form definition is nailed to the concept of the tabs
- presentation definition is entangled with the model
| FormDefinition separates field/property definitions from the layout definition
- Tabbed layout becomes just a concrete case of the layout definition
- We provide other types of layouting possibilities - HTML/Vaadin declarative layout/Custom Component
Possibly we introduce an alternative term 'editor' which is more generic than the form | Benefits - More flexibility
- Possibility to define complex fields with the same definitions that we use for the forms
- i.e. complex fields also become forms
Questions - How to provide compatibility between the current form definitions and the new ones?
- Resolve on programmatic level, i.e. allow special definitions that take the old one and then the app/dialog transforms them into the new ones?
|
...
I18N support in dialogs
Column definitions
...