Page History
...
- 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
- We proceed without affecting JCR adapters
- Filters
...
- 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
- Level 1: Make selection JCR agnostic
- TODO : create storyStory
- 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
Jira server Magnolia - Issue tracker key MGNLUI-2569 - define responsibillities
- diagram appreciated
- first concrete implementation is JCR
- 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
- TODO : createStoryStory
- Level 4: Redefine ContentPresenter apis
- TODO Story
- 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
- Further independent enhancements
- Workbench filters (dynamic / permanent)
- TODO Story in Ideas
- Single JCR Container
- TODO Story in Ideas
- Support for federated workbench / actions / search
- Workbench filters (dynamic / permanent)
- 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
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
...
Overview
Content Tools