Product Development

Page tree
Skip to end of metadata
  • Created on 2014-02-26, last edited by Mikaël Geljić on 2014-02-27
Go to start of metadata

This page describes changes from the current implementation of the JCR-agnostic content apps spike, where we still seek a general concept or where we look for architecture approval.

Status 2014.02.26

  • DataSource interface responsibilities
    • Mika yet to update diagram on JCR agnostic concept
    • we come with an idea how to deal with Containers/ContentPresenters in the future
      • ContainerConfiguration
    • Currently has two responsibilities
      • providing "data source" (Vaadin Container, Item)
      • translating itemId to URL fragment and vice-versa
    • Naming of the "data source" object
      • DataSource
      • ContentSource
      • ContentConnector
  • Configuration
    • "Stateless" object VS. Definition
    • see Proposed configuration below
  • ContentChangeEvent with just itemIds
    • should carry item?
    • to which "domain" an item belongs to?
    • are workspace/nodeType matching?
    • JcrContentChangeEvent ---> ContentChangeEvent ???
    • Current proposal: info.magnolia.ui.vaadin.integration.datasource.DataSource.hasItem(Object)
    • (star) Proposal: use a new JcrItemId type as Vaadin itemId rather than String uuid
      • workspace
      • identifier
      • Datasource #canHandle (basic type / property checking)
  • ActionExecutor and availability (Sasha)
    • we currently only split AvailabilityRule VS. JcrAvailabilityRule
    • yet to comes up with a sub-concept for the long run (ActionbarPresenter and/or ContextMenu doing availability checks)
    • draft impl of VoterBasedAvailability
      • Availability.isAvailableForItems
      • N2B transformer for node / properties / shorthands
  • Injecting DataSource
    • e.g. in EditItemAction
      • needs to create DetailLocation
    • injects dataSource
    • Current proposal: DataSourceProvider implements javax.inject.Provider and is registered only for subapp scope
      • only creates DataSources for ContentSubApps (browser/detail)
  • Action parameters
    • BrowserPresenter #prepareActionArgs
    • Current proposal: ActionEvent / Inplace editing
      • String actionName, Set<Object> itemIds, Map<String, Object> parameters
      • concrete cases
        • saveItemProperty needs propertyId and actual property
        • saveForm needs actual item or JCR adapter
      • placeholders
        • default execute action
        • default delete action
    • see in DirectUploadAction <=> ActionRenderers
      • BaseDialogPresenter exposes getActionParameters
      • passing UI context around from ActionRenderers via #onActionFired
    • need concept for passing set of expected parameters to Action
      • e.g. item vs. itemId vs. location path

 

Proposed configuration

  • subApps
    • browser
      • actions
        • editFolder
          • availability
      • actionbar
      • dataSource
        • class: info.magnolia.ui.contentapp.dsmanager.JcrDataSourceDefinition
        • workspace: contacts
        • rootPath: /
        • nodeTypes
        • includeProperties
        • includeSystemNodes
      • workbench
        • contentViews
    • detail
      • editor
        • nodeType
      • dataSource
        • extends: ../../browser/dataSource (/!\ duplicate instance)

 

Module structural changes

  • rename magnolia-ui-vaadin-integration >> magnolia-ui-vaadin-jcr-integration
    • adapters, as is currently
    • move jcr containers here
  • make workbench module (or subpackage) independent of vaadin-jcr-integration module
  • new module magnolia-ui-workbench-jcr depends on both
  • - NOT UP TO DATE
  • No labels