Concept - Architecture improvements

Current	Goal

Decisions

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

We create a new artifact magnolia-ui-api. It should be responsible for functionality that our UI constructs, workbench, actionbar etc requires. These features are:

• Modaility (Overlay)
• Messages/Notifications
• Actions
• View and Viewport interfaces

We create a new artifact magnolia-ui-imageprovider, it will contain the ImageProvider interface, the default implementation and the definition for the same.

The factory base classes that are currently in ui-model could be moved to magnolia-core.

We introduce an interface UIContext which is to be implemented by AppContext, SubAppContext and Shell. It will be injectable and always represents the current context.

Problems in the current architecture

The shell module depicted does not actually exist. It is currently in ui-framework and in common-widgets.

Rich text, link and upload fields are in ui-admincentral although they should be further down. Tickets exists for this.
Unable to locate Jira server for this macro. It may be due to Application Link configuration.  
Unable to locate Jira server for this macro. It may be due to Application Link configuration.  
Unable to locate Jira server for this macro. It may be due to Application Link configuration.  

The goal of removing ui-model has not yet been reached.

ImageProviderDefinition is in ui-model.

Actions are in ui-model.

common-widgets contains all our gwt widgets because we still don't have a solution for packaging them separately.

The view interface, part of the presenter-model-view pattern is in common-widgets.

Vaadin integration module should not depend on ui-model. Does so only for tests.

Meeting notes April 22nd

UI API (vs. Model)

• new artifact

  • name: magnolia-ui-api
  • the two new interfaces go in there
    
    • modality
    • messages
  • interfaces only

• what to do with the existing UI model

  • kill it
  • actions
    
    • ui-api
  • imageProviderDefinition
    
    • new module (only for classes)
  • base classes for factories
    
    • factory base -> could go to core

• other candidates for such a move

  • view and viewport interface (ads the dependency to Vaadin)
  • I18nAuthoringSupport -> should stay in the form
  • shell --> no usecase

new MyClass(modality, appContext)

• register it
• get the single instance, for instance the app context
• have two independent interfaces, the context implements both

Overlay