Page History

...

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 in DetailSubApp: 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

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

...

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

Image RemovedImage Added

Prototyping sessions

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.

Page tree

Versions Compared

Old Version 21

New Version Current

Key