Page History
...
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 typical behaviouran app.
These interfaces and classes are in magnolia-ui-framework.
The key interfaces are: App AppController AppContext SubAppContext.
The The implementation AppController and the location handling are in magnolia-ui-admincentral in the not so appropriate package name info.magnolia.ui.admincentral.app.simple.
Action: Find a better package structure
Action: Clean upp AppContext and SubAppContext from methods used internally only.
Proposal
.
Proposed Implementation
From An App Developers perspective
Approved Steps currently in development
- Convert abstract *Apps (AbstractApp, AbstractSubApp, ...) to concrete classes (BaseApp, BaseSubApp, ...)
- Interface for AppFrameView (AppView), inject interface into BaseApp
- AppView.Listener implemented by AppContext -> listens to AppView events
- remove tab dependency from events
- Remove vaadin dependencies from AppContext
- Rename AppContextImpl ->AppInstanceControllerImpl
- AppInstanceControllerImpl implements two interfaces:
- AppContext for contextual information relevant for the app
- AppInstanceController exposing the contract to the AppController
- AppController: use AppDescriptorRegistry instead of AppLauncherLayoutManager
Missing:
- According to Concept - Alternative ui-project organisation
move the package info.magnolia.ui.admincentralframework.app.simple into module AppController#getCurrentAppInstanceController- should go
- javadoc
- Create app framework specific interfaces for e.g. AppView, SubAppView
- SubAppView interface is still missing
- stop method in subapp
Maybes
- remove vaadin dependencies from magnolia-ui-framework
...
- Move info.magnolia.ui.framework.view.View into vaadin-integration
Additional Information
Documentation
UML Diagrams
Overview
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. Get rid of most subclasses. Inject 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 Used for opening the ChooseDialog. A relict from the time we had the workbench definition bound to the App. | Remove class and create an interface for ChooseDialog The idea of this class was serving the workbench configuration, as this has moved to the subApp there is no real usage for this class. The logic in there for serving a ChooseDialog hould be moved to an interface, so that the actual implementation of opening the Dialog is up to the App and not bound to the framework. |
AbstractSubApp | info |
...
The idea of AppContext is to expose functionality to the App. That is, to an instance of an app.
It should not expose methods that are only used by AppControllerImpl. These should be hidden from all other classes.
If necessary AppControllerImpl#runningApps should be changed to <String, AppContextImpl>. Also if the intention of AppContextImpl is unclear it should be renamed to reflect the fact that is not just the default implementation of AppContext, it does much more and in fact fullfils much of the contract defined by AppController.
...
.magnolia.ui.framework.app |
...
AppController
References
Abstract
see AbstractApp | convert to non-abstract - e.g. PageMainSubApp could go | |
AbstractItemSubApp | info.magnolia.ui.admincentral.app. |
...
content | see AbstractApp | convert to non-abstract- e.g. ContactsItemSubApp could completely go then |
AppController |
The App controller that manages the lifecycle of running apps and raises callbacks to the app.
|
...
|
Actions
The AppController is in general in a good shape. Interface is well defined and usages are legit.
Some technical ideas and questions
...
|
...
|
...
|
...
|
...
|
...
|
AppContext |
Shell Apps
Q: Do we plan any improvements here?
--> No
Q: Should we move it out of the App Framework and into AdminCentral as its not intended to be extended?
--> Yes
Tasks
Jira Issues | ||
---|---|---|
|
Documentation
UML Diagrams
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
Should not be depending of any vaadin dependencies.
| |||||||
AppContextImpl |
| |||||||
SubApp | All SubApp's are considered to be equal. We can flag one (or even more) to be the default - that's the one that will be opened first and that won't be closable. |
| ||||||
SubbAppContext | Basically in good shape - just offers a little too much. | Eliminate methods only relevant for the implementing types - not for someone writing an app. Basically we should question all setters on this interface.
| ||||||
AppDescriptor SubAppDescriptor | simply used for config |
| ||||||
AppFrameView | info.magnolia.ui.admincentral.app.simple | Used to give Apps a consistent view. Holds a MagnoliaTabSheet and a Listener interface which makes the AppContext dependant on MagnoliaTabs. |
|
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
Jira | ||||
---|---|---|---|---|
|