Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

This concept is a work-in-progress specification for decoupling content apps from JCR, due to land in Magnolia 5.3. In particular, it features:

  • Highlights on the various spots and components that are currently tied to JCR or to our adapters interfaces
  • A list of general issues with extending the behavior and appearance of content apps
  • Proposals and patterns for overcoming such issues.


1. User stories


2. Problems

Displaying non JCR content in the workbench

  • It is impossible to plug an external data source into the workbench
    • One can perhaps extend our default content presenters
      • TreePresenter, ListPresenter, ThumbnailPresenter, SearchPresenter
    • The container implementations are hard-coded in there
      • resp. HierarchicalJcrContainer, FlatJcrContainer, ThumbnailContainer, SearchJcrContainer
    • Then one needs to extend all of these desired presenters to hook in external content
    • And finally configure them as presenterClass on contentViews, or using custom ContentPresenterDefinitions
    • And yet the Workbench and Browser sub-app will complain/crash because custom container items are not representing JCR items.
  • Nor is it possible to filter JCR content easily
    • Similarly as above, to implement a simple filtering mechanism for a JCR workspace, one must still extend and reconfigure all content presenters.
      • e.g. security-app, forum moderation
  • Workbench and Browser APIs are inherently tied to JCR
    • WorkbenchDefinition may be reduced to the raw
  • How about Location and path in the status bar when dealing with non-JCR items?
    • One needs pluggable mechanisms to map these representations together:
      • content as Vaadin Item
      • content key (itemId) as provided by Vaadin Container
      • content key as a human-readable variant of the itemId (location handling, selection info)


Extending the workbench

  • It is almost impossible to replace/extend small parts of the workbench
    • e.g. hooking a custom WorkbenchPresenter or WorkbenchView
    • this requires to start from the very top with a custom BrowserSubApp class
    • then get a custom BrowserPresenter injected, which itself would eventually get the custom Workbench injected

Content-app architecture

  • String as one and only Vaadin item-id
  • Inconsistent listener/event-handler interfaces that sometimes transport item ids (Strings, not Objects), sometimes - Vaadin items or JCR items.
  • On all the layers of content app the JCR data is accessed via utils and/or Vaadin JCR adapters.


3. Proposals

  • 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
  • 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 
  • 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
  • expose preconfigured presenterClassfor browser / workbench / actionbar
    • so that customization doesn't always have to start at subApp level
  • We proceed without affecting JCR adapters

- To be completed




  • Entry points
    • Actions and execution
    • Workbench
    • Content views
    • Adapters (question)
  •  Milestones
    1. Read-only browser sub-app
    2. Actionable browser sub-app
    3. Creating / editing in dialogs
    4. Detail subapps


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
    • MGNLUI-1991 - Getting issue details... STATUS
  • Multiple actions deserve a review in the process
    • In particular, we should guarantee distinction between null and root selection.
    • Implementation needs review
  • Availability & Permissions
    • Availability is too complex and lacks permission-based assessments
    • ActionExecutor is not the best choice for evaluating action availability
    • See Permissions for UI availability



JCR all over the place

  • 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



  • No labels