Abstract
The goal is to finalize the API and settle for naming and feature set. The documentation, both javadoc and otherwise also needs to be improved.
The current packaging needs to be rethought. This is to be tackled in a separate effort (See Concept - package reorganisation concretes).
We should finalize the API in terms of finding the right level of abstraction. The API should guide the app developer and not expose internals.
Design
The framework is a set of interfaces and abstract utility classes that assist by implementing an app.
These interfaces and classes are in magnolia-ui-framework. The implementation AppController and the location handling are in magnolia-ui-admincentral.
Current Implementation
Proposed Implementation
Additional Information
Documentation
UML Diagrams
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 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?
SubAppContext
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.
Basically we should question all setters on this interface.
- e.g. setAppContext(AppContext)
- this should automatically happen behind the scenes (in the impl) - don't see why someone should explicitly call it from outside
(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?
Additional thoughts from first review
- we should try to extract locationManagement
3) AppContextImpl
-> find better name, it's more than an Impl of an AppContext
-> one option (Tobias' propsal): rename AppController -> AppManager & AppContextImpl -> AppController
4) AppLauncherLayoutManager
- only the AppLauncher should use it
5) structuring of modules: admin-central & framework: check whether AppContextImpl can to framework
-> frist streamline the interfaces
6) Should Main Subapp be an explicit type - we don't want to be able to overwrite.
7) Security App: this is the most exceptional one - will it be split into several apps or not? If yes, we could App Framework could be simplified even more
Next Steps:
Espen & me will do some further investigations, prepare better concept with clear decision points and contact u again for review - we won't do any coding for before then.
Tasks