Page History

...

Concept work will be tracked by the following Epic:

...

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

 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

1. 1. Jira
      server Magnolia - Issue tracker key MGNLUI-2657

   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

Level 2: Redefine Browser / Workbench apis

1. 1. Jira
      server Magnolia - Issue tracker key MGNLUI-2569

   2. define responsibillities
      
1. diagram appreciated
2. 1. first concrete implementation is JCR
      1. diagram appreciated
   2. also focus on a different implementation (FileSystem, Bean) to uncover potential problems
   3. try to include proposal #6 (e.g. exposing Workbench presenterClass)

Level 3: Dialogs and DetailSubApps

1. 1. Jira
      server Magnolia - Issue tracker key MGNLUI-2656

Level 4: Redefine ContentPresenter apis

1. 1. Jira
      server Magnolia - Issue tracker key MGNLUI-2658

   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

...

Independent enhancements 

• • Workbench filters (dynamic / permanent)
    
    • TODO Story in Ideas
  • Single JCR Container
    Support for federated workbench / actions / search

    • Jira
      server Magnolia - Issue tracker key BL-153

Support for federated workbench / actions / search
 We don't affect JCR adapters

4. Connected topics

•  Actionbar 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

  • Jira
    server Magnolia - Issue tracker key MGNLUI-1991

  • 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

...