Versions Compared

Old Version 7

changes.mady.by.user Aleksandr Pchelintcev

Saved on

compared with

New Version 8

changes.mady.by.user Aleksandr Pchelintcev

Saved on

Key

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

...

  • 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

An attempt was made to extract all the JCR-dependent logic from the BrowserSubApp-related presenters into child classes. The goal was to keep the interfaces the same as possible, just to clear the implementation. 

0001-jcr-free-browser-subapp.patch