JCR-agnostic content apps

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

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

1. 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
2. Map Vaadin Items to ItemIds to Human-readable location at Browser level
3. 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)
4. 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
5. 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
6. Expose preconfigured presenterClass for browser / workbench / actionbar
   
   • so that customization doesn't always have to start at subApp level
7. 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

1. Level 1: Make selection JCR agnostic
   1. MGNLUI-2657 - Getting issue details... STATUS
   2. generalize JcrAdapters into Vaadin Items
   3. generalize String ids into Object itemIds
   4. Handle multiple selection nicely (e.g. avoid converting sets into lists, items to itemIds)
   5. try not to use Items when itemId is sufficient (events)
   6. No big API breaking
2. Level 2: Redefine Browser / Workbench apis
   1. MGNLUI-2569 - Getting issue details... STATUS
      
   2. define responsibillities
      
      1. diagram appreciated
   3. first concrete implementation is JCR
   4. also focus on a different implementation (FileSystem, Bean) to uncover potential problems
   5. try to include proposal #6 (e.g. exposing Workbench presenterClass)
3. Level 3: Dialogs and DetailSubApps
   1. MGNLUI-2656 - Getting issue details... STATUS
4. Level 4: Redefine ContentPresenter apis
   1. MGNLUI-2658 - Getting issue details... STATUS
   2. make content views less workbench and JCR dependent
   3. container properties / operations may belong to workbench
      
      1. VS. list only requires visible columns, width...
   4. one should think about filters upfront
      
      1. think about facets at workbench level

• Further 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
    
    
•  We don't affect JCR adapters

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

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

0001-jcr-free-patch-dam.patch