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

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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

 

 

Proposal

  • 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

Proposal

 

Advantages

  • 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