JCR-agnostic content apps

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.
• 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
• Workbench and Browser APIs are inherently tied to JCR
  
  • 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)

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
• 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
  
  1. Read-only browser sub-app
  2. Actionable browser sub-app
  3. Creating / editing in dialogs
  4. 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