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
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)
|
...