Related repos:
Project with UI framework extensions and reference content app implementation: https://git.magnolia-cms.com/users/apchelintcev/repos/content-app-poc/browse
UI fork with necessary minimal changes: https://git.magnolia-cms.com/users/jsimak/repos/ui-bottom-lift/browse
Related JIRA issues:
| 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-769 |
|---|
|
...
| Reasons to bother | What changes | Outcome |
|---|
Quirky way of communicating the data source changes - Requires manual actions of both sending the events and handling them. I.e. if I change smth in JCR and forget to send CCE, no one will ever know.
- Apps that are not related to the changed data source still have to handle its CCE and see if they should react (hence
ContentConnector#canHandleItem).
| We should try to expose the data source observation utilities and subscribe to them where needed. - e.g. we have already the JCR observation mechanism that Vaadin's
DataProvider can subscribe to in this or that way and just push the change notification to the UI automatically. - Whenever we change smth in the data source the UI is notified eventually.
- For the data sources that do not have real time observation, we could easily provide a timer-based implementation that merely refreshes the UI periodically.
| Benefits - Clear and re-usable data source observation mechanism.
- Less boilerplate for the app developers
Questions  Need to provide un-registration strategy. For some cases a mere weak-hashmap solution might work . We though should also make sure that once the view is dead, no observation left-overs are still hanging around
|
Field definitions
| Reasons to bother | What changes | Benefits |
|---|
- Not generic
- value type is communicated in "JCR" style, i.e. via strings
| FieldDefinition becomes generic
| Better compatibility with the new, more type-safe Vaadin data-binding API's |
Form definition
| 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
...