Page History
...
Here's the key types and our thoughts about them:
App
Currently the AppFrameView is created and managed by the AppContext.
- we can simplify the AppContext and remove the dependency on AppFrameView.
- Inject AppView (interface of AppFrameView) into BaseApp. make start return AppView.
- add tab etc to the app, delegate to appframeview from there. get rid of frameview dependency from appcontroller and appcontext.
- do not make appContext a listener of appFrameView. app is listening to events and delegates to appContext. get rif of magnoliaTab dependency in the AppFrameView.Listener
Where is mapping between MagnoliaTab and SubApp? -> AppFrameView implementation or SubAppView?
Reintroduce tab to tabId in MagnoliaShell. Use com.vaadin.server.KeyMapper? Kepp in mind that there can be multiple subApps open with subAppId, needs a unique identifier
MagnoliaTab is SubAppView !
We are using abstract classes where no longer necessary. So we end up creating App classes extending AbstractApp, only because the class is abstract.
...
Type | Location | Status Quo | Proposed Action |
---|---|---|---|
AbstractApp
| info.magnolia.ui.framework.app | abstract but many subclasses (e.g. PagesApp, MessagesApp) don't add additional functionality | convert to non-abstract type & rename to BaseApp, DefaultApp or AppImpl - same for AbstractContentApp, AbstractItemApp. Get rid of most subclasses. Iject the AppContext and App(Frame)View directly into the AbstractApp instead of passing it from the AppClass. |
AbstractContentApp | info.magnolia.ui.admincentral.app.content |
...
see AbstractApp |
...
convert to non-abstract type | |
AppController |
The AppController is in general in a good shape. Interface is well defined and usages are legit.
...
The App controller that manages the lifecycle of running apps and raises callbacks to the app.
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
AppContext |
...
...
The AppContext serves multiple different purposes:
|
...
The general problem: used heavily by the appController and also for the app itself to get contextual information: serving multiple needs. see
| |||||||
AppContextImpl |
...
|
Here's the key types and our thoughts about them:
App
Currently the AppFrameView is created and managed by the AppContext.
- we can simplify the AppContext and remove the dependency on AppFrameView.
- Inject AppView (interface of AppFrameView) into BaseApp. make start return AppView.
- add tab etc to the app, delegate to appframeview from there. get rid of frameview dependency from appcontroller and appcontext.
- do not make appContext a listener of appFrameView. app is listening to events and delegates to appContext. get rif of magnoliaTab dependency in the AppFrameView.Listener
Where is mapping between MagnoliaTab and SubApp? -> AppFrameView implementation or SubAppView?
Reintroduce tab to tabId in MagnoliaShell. Use com.vaadin.server.KeyMapper? Kepp in mind that there can be multiple subApps open with subAppId, needs a unique identifier
MagnoliaTab is SubAppView !
SubApp
- No App without a "Main Subapp" / SecurityApp (only subapps of same level will have to change - discussed with Andreas + Philipp)
- Should Main Subapp be an explicit type - or inlined in real App?
- we don't want to be able to overwrite
- Should Main Subapp be an explicit type - or inlined in real App?
...
Basically in good shape - just offers a little too much.
Abstract
The SubAppContext serves multiple different purposes:
Open Issues
Eliminate methods only relevant for the implementing types - not for someone writing an app.
...
(Sub)AppDescriptor
Basically in good shape
Abstract
These are simply used for configuration
Open Issues
- trivial: create common super-interface (class for the Configured impl's) - 90% of the code is identical
- replace explicit setting of default by order of subapps?
...