Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Level 1: Make selection JCR agnostic

  1. Jira
    serverMagnolia - Issue tracker
  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

  • Jira
    serverMagnolia - Issue tracker


  • 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
      // isn't i18n useless on this definition?
      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
    serverMagnolia - Issue tracker
  • 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
      titleDataSourceManager 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
    serverMagnolia - Issue tracker
  • 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 (question)

  • Workbench filters (dynamic / permanent)
    • TODO Story in Ideas
  • Single JCR Container
    • Jira
      serverMagnolia - Issue tracker
  • 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
      serverMagnolia - Issue tracker
    • 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


Workbench/JCR split

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.