Page tree
Skip to end of metadata
Go to start of metadata

App Configuration

Summary

links to meeting notes:

Thoughts on Naming ContentApp

Dialogs vs. Forms

There are some shortcomings in the current configuration, e.g:

  • Dialogs are used for editing items, should be named forms
    • dialogs should still be used as before, but they conatin a form subnode with the field definitions
    • forms have no central registry. They can be defined where needed. E.g. in dialogs or for a nodeType
  • workbench used for all configuration. Should be splitted so that actionbar and imageprovider and so on are not depending on a workbench. The workbench should be reserved for "Workbench SubApps"
  • nodeTypes should be defined differently for the UI. Also not depending on the workbench
    • nodeTypes can contain a form Subnode which defines the fields
    • nodeTypes should go up in the hierarchy. If two subApps work on the same nodeTypes, they should not have to be defined per subApps, or even for multiple Apps -> use central regisistry
  • the form for editing
  • definitionsToImplementations should be renamed to just "mappings"

Current

Proposal

Renaming

Summary

We don't have a proper naming concept. The used names are confusing and not used consequently.

ContentSubApp: Currently a workspace browser w/ list,tree and thumbnail view.

ItemSubApp -> Used for viewing and editing an item

Workbench -> What is this. We used to call the main configuration this. Also there are code references at strange places. ContentWorkbench.. , WorkbenchDefinition

  • What is a workbench?
    • A workbench is the general view of a subApp
    • it holds a view on left for some "content" (not necessarily jcr content as opposed to a contentWorkbench) and e.g. an actionbar on the right
    • as most configuration goes into a workbenchDefinition this has to be a general definition of the word
  • what is contentWorkbench
    • it's used for list/tree/thumbnail view. In most/all cases this view represents a JCR-view
  • dialog -> form/editor  preview/details

Note by jan:

any reason we call it subapp? I understand that you don't want to call it "tab" since that would be view specific and might change in the future if we change view, otoh it doesn't feel right calling it subapp either. Can we at least try to think of other name? AppComponent maybe?

Proposal

We need to rename the the term "ContentSubApp". It's confusing. Also the term ContentApp maybe?

  • WorkspaceBrowser. WorkspaceSubApp
  • WorkbenchSubApp - we already use the term workbench for this subApp

Workbench

  • workbench is currently used
  • No labels

1 Comment

  1. It seems we'll need a standard way to prevent naming collisions in the names of apps. The documentation states: (App frameworkname. Name of the app. The name must be unique as it is used to refer to the app across the system. This means you cannot name your app pages since an app by that name already exists.

    I would suggest the same approach as classes in java: using the reverse qualified domain name of the company. So the name, the unique reference of the pages app goes from "pages" to "info.magnolia.pages". Or at least "magnolia.pages". One could argue that magnolias own apps dont need a qualifier, but I would argue that it would make it clearer and encourage 3rd party developers to follow the pattern if we would rename our apps in this way.