Page History

...

• 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

• Transfer 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
• We proceed without affecting JCR adapters

...