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

Compare with Current View Page History

« Previous Version 33 Next »

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.

Design

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.

App Framework

The framework is a set of interfaces and abstract utility classes that assist by implementing typical behaviour.

These interfaces and classes are in magnolia-ui-framework.

The key interfaces are: App AppController AppContext SubAppContext.

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

  • According to Concept - Alternative ui-project organisation
    • move the package info.magnolia.ui.admincentral.app.simple into module magnolia-ui-framework e.g. info.magnolia.ui.framework.app.api (NOTE: this contradicts decision made for shell apps, see further down)
    • or jus out of the simple subpackage
  • info.magnolia.ui.admincentral.app.simple.AppContextImpl
    • general problem: used heavily by the appController and also for the app itself to get contextual information: serving two needs. see http://jira.magnolia-cms.com/browse/MGNLUI-403

      • 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.

      • rename the AppController to AppLauncher or similar, introduce a new AppController class which takes care of the contract to the AppLauncher and keep the AppContext as thin as possible, only serving contextual information to the actual App
      • Move some of the functionality of AppContext into the info.magnolia.ui.framework.app.launcherlayout.AppLauncherGroupEntry
        • info.magnolia.ui.admincentral.app.simple.AppContextImpl#getDefaultSubAppDescriptor
        • info.magnolia.ui.admincentral.app.simple.AppContextImpl#getSubAppDescriptorById

AppController

References

UML Diagram

App Framework

Abstract

The App controller that manages the lifecycle of running apps and raises callbacks to the app.
It provides methods to start, stop and focus already running {@link App}s.
Registers handlers to the following location change events triggered by the {@link LocationController}:

  • LocationChangedEvent
  • LocationChangeRequestedEvent

Usages

  • The AppController takes care of LocationChangedEvents coming from info.magnolia.ui.admincentral.app.simple.AppControllerImpl#onLocationChanged which can for example be fired by the info.magnolia.ui.framework.location.LocationController#goTo when clicking on icon in the AppLauncher. It takes the Location passed and extracts AppName and subAppId and gets the corresponding AppDescriptor from the info.magnolia.ui.framework.app.launcherlayout.AppLauncherLayoutManager.
  • It creates a new AppContext for the App
  • keeps history of running app and currently focused app
  • used by the MagnoliaShell to query the current Status of the appController
  • Used by FieldBuilders to get the AppContext and ComponentProviders for opening ChooseDialogs.

Actions

The AppController is in general in a good shape. Interface is well defined and usages are legit.

Some technical ideas and questions

general question:
usage of FocusEvent: seems to not be used consistently. Could also be extended to get rid of the setViewPort and associated calls

usage of appId is should be changed to appName

some methods take the appId and the location as parameter, appId is part of the location

info.magnolia.ui.admincentral.app.simple.AppControllerImpl#setViewPort
use focus event instead?

info.magnolia.ui.admincentral.app.simple.AppControllerImpl#getAppWithoutStarting
apparently the idea was to actually start the app for this usage

info.magnolia.ui.admincentral.app.simple.AppControllerImpl#startIfNotAlreadyRunningThenFocus
only used in test cases. see general question about focusEvent

info.magnolia.ui.admincentral.app.simple.AppControllerImpl#startIfNotAlreadyRunning
deprecated, maybe not right, see focusEvent

info.magnolia.ui.admincentral.app.simple.AppControllerImpl#doStartIfNotAlreadyRunning
this also checks if the app is running, if so it delegates to that app.. wrong naming

info.magnolia.ui.admincentral.app.simple.AppControllerImpl#stopApp
only used internally

info.magnolia.ui.admincentral.app.simple.AppControllerImpl#onLocationChanged
too heavy, should delegate to methods rather, see focusEvent

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

type key summary assignee reporter priority status resolution created updated due

Data cannot be retrieved due to an unexpected error.

View these issues in Jira

Documentation

Developing an app

UML Diagrams

AppContextImpl.png

 

 

 

  • No labels