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.
1. User stories
- MGNLUI-2569 - Getting issue details... STATUS
2. 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.
3. 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 presenterClassfor browser / workbench / actionbar
- so that customization doesn't always have to start at subApp level
- We proceed without affecting JCR adapters
- To be completed
Process
- Entry points
- Actions and execution
- Workbench
- Content views
- Adapters
- Milestones
- Read-only browser sub-app
- Actionable browser sub-app
- Creating / editing in dialogs
- Detail subapps
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
- Multiple actions deserve a review in the process
- In particular, we should guarantee distinction between null and root selection.
- Implementation needs review
- Availability & Permissions
- 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
An attempt was made to extract all the JCR-dependent logic from the BrowserSubApp-related presenters into child classes. The goal was to keep the interfaces the same as possible, just to clear the implementation.
0001-jcr-free-browser-subapp.patch
Overview
Content Tools