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

Starting Position

When dealing with SubApps that don't inherit from AbstractContentSubApp you have to re-implement most its code.

We want to simplify and standardize as much as possible.

We want more configuration and less code for App/SubApp generation.

ContentSubApp vs Non-ContentSubApp




  • Push as much code as possible into the AbstractSubapp, keeping only Content relevant code inside the AbstractContentSubApp
  • Introduce a Abstract"Item"SubApp on the same level as Content to handle Tabbed Editing of Items
  • ActionBar should be simpler to integrate somehow (question)
  • ContentWorkbenchPresenter vs WorkBenchPresenter
    • ActionBar, ImageProvider (basically everything in the Constructor is also relevant for Non-ContentSubApps) should not be depending on ContentWorkbench, but rather a superclass WorkBenchPresenter (ContentWorkbenchPresenter extends WorkbenchPresenter)

SubApp Configuration

Currently there is no proper way to configure subApps.

To overcome this, e.g. to use a different actionBar configuration we add another workBench Definition and extend the ConfiguredContentAppDescriptor




  • App knows from configuration what SubApps are available
    • makes the location handling simpler. Not passing SubApp names around to change location.
    • SubApp name not in code
  • ActionBar, Icon for tab, ... per SubApp possible 

Open Questions

One or two SubApp for preview and editing?

ActionBar configuration 1:1 with subapp?


  • No labels