Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated diagram to be realistic with updated approach; added meeting notes.

...

  • 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

(tick) Generally accepted:

  • ContentConnector gets green light
  • Events, JcrItemId get green light
  • ContentPresenters are OK with minimal changes
  • ImageProvider is OK with minimal changes

(minus) 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

(warning) 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.