Editor Config Access / Expose Infos

ld-discussion.md

Expose a li object on window

• throw events when ready
• more simple access
• better for testability

window.li = {
  session,
  contentBehavior,
  projectBehavior,
  config: {
    project,
    design,
    // static server config
    server,
    // static editor config
    editor,
  }
}

// register/listen on events
- onConfigReady,
- onSessionReady,
- onSessionUpdate,
- onSessionDestroy,
- onContentBehavorReady,
- ...
- onProjectBehaviorReady,
- ...

Behavior in Editor

• what is project behavior
  • project wide computed properties
• what is content behavior
  • document wide computed properties
  • content behavior is created whenever a new document will be openend

Input from Lukas

Content Behavior - Input from Lukas

ContentBehavior ist die aktuelle config für den Dokumenten-Editor für ein spezifisches Dokument. Sie wird beim öffnen von jedem Dokument neu berechnet. Mögliche Quellen für Einstellungen sind die project-config speziell die aktuelle content-type config, die editor confing, die server config oder auch User spezifische Configs.

Dank dem contentBehavior ist es jetzt einfach zu wissen welche config tatsächlich aktive ist wenn man ein Dokument öffnet und man kann auch einfach features spezifisch konfigurieren beim debuggen. Ebenso ist es einfach möglich in unit oder integration tests den Editor in allen möglichen Konfigurationen zu testen (man kann einfach eine spezifische config injecten beim Erstellen eines Workspaces in den tests du kannst hierfür den scenario helper ansehen).

Project Behavior - Input from Lukas

As I heard some questions regarding the projectBehavior. So here’s some more info what that is meant to be: The project behavior is the equivalent to the content behavior for the whole editor. It is a declarative resolved config the gets computed at session start and that can be accessed from everywhere in a read-only way. To compute the behavior the following should be taken into account:

• projectConfig
• serverConfig
• editorConfig
• user permissions
• user preferences
• device capabilities From a consumer perspective the behavior tells you what you should actually do or render in the editor as this is often a result of multiple configs, permissions and preferences. The behavior directly tells the editor what to do so it makes debugging easier as it can simply be logged out at any time to check if the editor is behaving. And in testing it is trivial to simply construct a desired behavior to test a module. It is not necessary then to e.g. stub user permissions to test if a component does the right thing, you can simply inject a specific behavior.

Project Behavior - Input from Beni (behavior vs session)

It's hard and not so clear from the current distribution of information between session and behavior. In my opinion the raw config doesn't belong in the behavior and it's perfectly fine to have it in the session.

We should do a cleanup over at behavior/session once (maybe with making part of these things reactive POJOs). Maybe it the whole story gets more clear then.

Introduce a Design Decision Document

When we write down the important decisions (which can not be implemented in one step and need time), people can look on the current state which path we want to take in the future.

Present Example:

• move functions of storage to *proxy entities and get rid of storage