Page History
...
Table of Contents | ||
---|---|---|
|
Concept work will be tracked by the following Epic:
Jira | ||||
---|---|---|---|---|
|
...
- 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
- 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
Jira server Magnolia - Issue tracker key MGNLUI-2657 - 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 responsibilities of components
- from BrowserSubApp down to WorkbenchPresenter
- we leave ContentPresenters as much unchanged as possible (maybe just passing current containers from above)
- We try to reduce WorkbenchDefinition's omnipresence
- in particular from Browser, Container; also from ContentPresenters (although unlikely at this step)
...
- first concrete implementation is JCR
- also focus on a different implementation (FileSystem, Bean) to uncover potential problems
...
- include proposal #6 (e.g. exposing Workbench presenterClass)
- Subtasks
- Untie JCR containers from WorkbenchDefinition - so that they (or at least AbstractJcrContainer) can be moved to vaadin-integration module
- Get WorkbenchPresenter from componentProvider, not through @Inject (different presenterClasses per WorkbenchDefinition)
Split WorkbenchDefinition from JcrWorkbenchDefinition, WorkbenchPresenter from JcrWorkbenchPresenter
Code Block language java title WorkbenchDefinition.java collapse true // isn't i18n useless on this definition? @I18nable public interface WorkbenchDefinition { String getName(); // JCR dependent; should move to JcrWorkbenchDefinition String getWorkspace(); String getPath(); List<NodeTypeDefinition> getNodeTypes(); boolean isIncludeProperties(); boolean isIncludeSystemNodes(); // Should be removed or moved (not in level 2) boolean isDialogWorkbench(); // doesn't belong to config String getDefaultOrder(); // belongs to ListPresenterDefinition boolean isEditable(); // belongs (currently) only to TreePresenterDefinition Class<? extends DropConstraint> getDropConstraintClass(); // belongs (currently) only to TreePresenterDefinition List<ContentPresenterDefinition> getContentViews(); // New config options Class<? extends Container> getContainerClass(); // preset in code for JCR if/when unified container is around Class<? extends WorkbenchPresenter> getPresenterClass(); // preset in code for JCR }
Level 3: Dialogs and DetailSubApps
Jira server Magnolia - Issue tracker key MGNLUI-2656 - DetailSubApps as well as Dialogs depend on JCR but not tightly - once the previous steps are completed it should be possible to completely get rid of JCR dependency without even extracting the child classes.
- The similar data management tasks that we have in
BrowserSubApp
occur inDetailSubApp:
we need to serialize/de-serialize item ids to fragments, query items by item id etc.- A reasonable solution would be to share a capable component between sub-apps.
- As long as content apps work over same domain - we could introduce the
DataSourceManager
component shared between sub-apps. It would encapsulate the solution of most of Level1/Level3 problems and could be useful for all other components that would need to connect to data of the app. DataSourceManager initial interface could look as follows for starters.
Code Block language java title DataSourceManager interface public interface DataSourceManager { String serializeItemId(Object itemId); Object deserializeItemId(String strPath); Item getItemById(Object itemId); Object getItemId(Item item); boolean itemExists(Object itemId); }
Level 4: Redefine ContentPresenter apis
Jira server Magnolia - Issue tracker key MGNLUI-2658 - make content views less workbench and JCR dependent
- container properties / operations may belong to workbench
- VS. list only requires visible columns, width...
- Ideally:
ContentView start(ContentPresenterDefinition definition, Container containerDataSource);
- one should think about filters upfront
- think about facets at workbench level
- Subtasks
- Use an action for inplace-editing
- Get rid of listener mechanism for getIcon - pass such configuration on presenter startup
Independent enhancements
- Workbench filters (dynamic / permanent)
- TODO Story in Ideas
- Single JCR Container
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
...
- 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
...
SubApp / 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
See the child page referenced below for the details of prototyping/research made in order to estimate/clarify the effort of making content apps JCR agnostic.
Meeting notes 2014.03.04
Generally accepted:
- ContentConnector gets green light
- Events, JcrItemId get green light
- ContentPresenters are OK with minimal changes
- ImageProvider is OK, the interface should be reviewed and cleared from the unnecessary methods.
Action availability is critical
- No definition should perform business logic
- We need to be very careful about using Voters
- We need to guarantee permissions are generally set the same way for apps, app groups, actions, etc.
- We may well differentiate permission availability from UI state based availability
Require consolidation
- DetailSubApp needs more understanding
- Actions with specific set of parameters
- Transformers, Fields
- we should guarantee detail view works for basic fields (text, checkbox)
- we may try plugin in a SQL database although practically it would be very similar to the filesystem app use case.