This concept is a work-in-progress specification for decoupling content apps from JCR, due to land in Magnolia 5.3. In particular, it features:
- Highlights on the various spots and components that are currently tied to JCR or to our adapters interfaces
- A list of general issues with extending the behavior and appearance of content apps
- Proposals and patterns for overcoming such issues.
Concept work will be tracked by the following Epic:
MGNLUI-2655 - Getting issue details... STATUS
1. Problems
Displaying non JCR content in the workbench
- It is impossible to plug an external data source into the workbench
- One can perhaps extend our default content presenters
- TreePresenter, ListPresenter, ThumbnailPresenter, SearchPresenter
- The container implementations are hard-coded in there
- resp. HierarchicalJcrContainer, FlatJcrContainer, ThumbnailContainer, SearchJcrContainer
- Then one needs to extend all of these desired presenters to hook in external content
- And finally configure them as presenterClass on contentViews, or using custom ContentPresenterDefinitions
- And yet the Workbench and Browser sub-app will complain/crash because custom container items are not representing JCR items.
- One can perhaps extend our default content presenters
- Nor is it possible to filter JCR content easily
- Similarly as above, to implement a simple filtering mechanism for a JCR workspace, one must still extend and reconfigure all content presenters.
- e.g. security-app, forum moderation
- Similarly as above, to implement a simple filtering mechanism for a JCR workspace, one must still extend and reconfigure all content presenters.
- Workbench and Browser APIs are inherently tied to JCR
- Event the view implementations are depending on JCR/JcrAdapters (e.g. TreeViewImpl)
- WorkbenchDefinition may be reduced to the raw
- How about Location and path in the status bar when dealing with non-JCR items?
- One needs pluggable mechanisms to map these representations together:
- content as Vaadin Item
- content key (itemId) as provided by Vaadin Container
- content key as a human-readable variant of the itemId (location handling, selection info)
- One needs pluggable mechanisms to map these representations together:
Extending the workbench
- It is almost impossible to replace/extend small parts of the workbench
- e.g. hooking a custom WorkbenchPresenter or WorkbenchView
- this requires to start from the very top with a custom BrowserSubApp class
- then get a custom BrowserPresenter injected, which itself would eventually get the custom Workbench injected
Content-app architecture
- String as one and only Vaadin item-id
- Inconsistent listener/event-handler interfaces that sometimes transport item ids (Strings, not Objects), sometimes - Vaadin items or JCR items.
- On all the layers of content app the JCR data is accessed via utils and/or Vaadin JCR adapters.
2. Proposals
- Propagate Vaadin selection transparently up till action execution
- as a Vaadin Item or a Set of Vaadin Items
- so that executor doesn't care about data source
- as a Vaadin Item or a Set of Vaadin Items
- Map Vaadin Items to ItemIds to Human-readable location at Browser level
- Split WorkbenchDefinition from JcrWorkbenchDefinition
- Configure a containerClass in code - can be overridden in config
- Have a JcrBrowserSubAppDescriptor that overrides #getWorkbench() with JCR specific workbench definition type
- see Appendix diagram (Workbench/JCR split)
- Unify all JCR Containers at workbench level
- They represent the same data set
- JCR is by nature Hierarchical, Indexed and Ordered
- Advanced behaviors can surely be delegated to smaller units (search, filters)
- Thumbnail resolution is not among container duties
- Research how a ContentPresenter can start with just ContentPresenterDefinition and Container to populate itself
- avoid to carry WorkbenchDefinition along everywhere
- in a similar fashion as DetailPresenter#start(EditorDefinition, JcrNodeAdapter, ViewType)
- Restructure ContentPresenter and Workbench definitions
- editable and dragDropHandler belong to content views - they do not necessarily apply to all
- columns should belong to a ListPresenterDefinition interface - they do not apply to thumbnails or any arbitrary other content view
- Expose preconfigured presenterClass for browser / workbench / actionbar
- so that customization doesn't always have to start at subApp level
- Filters
- dynamic filters through the UI, e.g. asset filtering (images, documents, videos)
- permanent filters by configuration or in code (e.g. forum moderation)
- define facets
- at workbench level - concretely setting container properties
- ≠ list view's ColumnDefinitions; they would be based on a facet, but describe only visual appearance (visible columns, headers, sizes)
- a facet describes whether it is: sortable, filterable , maybe even which UI should be used to filter it (e.g. ranges, text, enums)
- filters apply to any content view
3. Proposed milestones
We may first reapply the Action bar MVP and dependency refactoring that was meant for 5.1, as a sanity rebase.
We don't affect JCR adapters
Level 1: Make selection JCR agnostic
- MGNLUI-2657 - Getting issue details... STATUS
- generalize JcrAdapters into Vaadin Items
- generalize String ids into Object itemIds
- Handle multiple selection nicely (e.g. avoid converting sets into lists, items to itemIds)
- try not to use Items when itemId is sufficient (events)
- No big API breaking
Level 2: Redefine Browser / Workbench apis
- MGNLUI-2569 - Getting issue details... STATUS
- define responsibillities
first concrete implementation is JCR- diagram appreciated
- also focus on a different implementation (FileSystem, Bean) to uncover potential problems
- try to include proposal #6 (e.g. exposing Workbench presenterClass)
Level 3: Dialogs and DetailSubApps
- MGNLUI-2656 - Getting issue details... STATUS
- DetailSubApps as well as Dialogs depend on JCR but not tightly - once the previous steps are completed it should be possible to completely get rid of JCR dependency without even extracting the child classes.
- The similar data management tasks that we have in
BrowserSubApp
occur inDetailSubApp.
Level 4: Redefine ContentPresenter apis
- MGNLUI-2658 - Getting issue details... STATUS
- make content views less workbench and JCR dependent
- container properties / operations may belong to workbench
- VS. list only requires visible columns, width...
- one should think about filters upfront
- think about facets at workbench level
Independent enhancements
- Workbench filters (dynamic / permanent)
- TODO Story in Ideas
- Single JCR Container
- BL-153 - Getting issue details... STATUS
- Support for federated workbench / actions / search
- Workbench filters (dynamic / permanent)
4. Connected topics
- Actionbar dependency and MVP
- common-widgets shouldn't depend on ui-api
- Actionbar currently implements the View interface (ui-api) instead of having the ActionbarPresenter produce a ViewImpl
- Revived refactoring that was postponed for 5.1, in favor of the i18n merge
- MGNLUI-1991 - Getting issue details... STATUS
- Make sure content views no longer getIcon via listener
- Multiple actions deserve a review in the process
- In particular, we should guarantee distinction between null and root selection.
- Implementation needs review
- Availability & Permissions - independent
- Availability is too complex and lacks permission-based assessments
- ActionExecutor is not the best choice for evaluating action availability
- See Permissions for UI availability
Appendix
JCR all over the place
- ActionExecutor
- availability depends on JCR Item
- Actions
- OpenCreateDialogAction creates JcrNewNodeAdapter
- OpenEditDialogAction, SaveDialogAction all deal with JcrAdapter
- SaveDialogAction relies on adapter applying its own changes
- Requires a generic hook for saving?
- JcrSaveAction implicitly configured for all forms?
- Actions on items from external data sources require their own actions
- default set of actions with a different implementation catalogs?
- configure save action on openDialog/Form action
- Adapters
- should not perform JCR operations
- should be stupid readonly representations of JCR Item as Vaadin Item
- Transformers
- BasicTransformer (root impl of all) relies on DefaultPropertyUtil, that is implicitely on JCR propertyTypes
- Containers
- As is, all containers should be replaced for all content views
- Consider getting workbench unified container onboard so that users don't need to configure n containers
- Or chances are that they would be smarter than us and use a single one, configured in multiple locations
- Components / Presenters
- Workbench / BrowserSubApp / ContentPresenters / Events
Workbench/JCR split
Prototyping sessions
See the child page referenced below for the details of prototyping/research made in order to estimate/clarify the effort of making content apps JCR agnostic.