Der Nutzer hat die Möglichkeit in der Anwendung selbst Typen zu definieren. Er soll auch in der Lage sein im Layout sich ein neues Layout zu erstellen mit dem er Objekte eines solchen Types anzeigen, bzw. bearbeiten kann.

Umsetzung

• Layout-Konfigurationen werden in der Datenbank abgelegt select * from layout_configurations;
• Dynamisch instanziierbare Layout-Templates sind über typisierte Konfiguration parametrisiert (<config:template/>).
  • Parameter werden als Property-Descriptors konfiguriert (properties/property)

#!xml
<config:template xmlns:config="http://www.top-logic.com/ns/config/6.0">
   <properties>   <!-- Config-Deskriptor für das Argument-Objekt -->
      <property name="type"
         mandatory="true"
         type="String"
      />
   </properties>

   ...
</config:template>

• Eingebunden werden dynamische Layput-Templates über <config:template-call> mit einem arguments-Config-Item

#!xml
<config:template-call template="com.top_logic.element/dynamic/gridByType.xml">
   <!-- Argument-Objekt passend zum Config-Descriptor aus der Template-Datei. -->
   <arguments type="ohlfElement:OrgUnitFinance"/>
</config:template-call>

Code-Migration

• Tab-Bar-Sichten auf typisierte Templates umstellen.
  • Dazu muss das templates/tabbar.xml include Tag durch ein arguments Tag ersetzt werden, welches wiederum in ein

{{{
#!xml
<config:template-call

xmlns:config="http://www.top-logic.com/ns/config/6.0" template="com.top_logic/legacyTabbar.template.xml"

>
</config>
}}}

gewrappt werden muss. Bspw. wird
{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>

<include name="templates/tabbar.xml"
helpIDLegacy="main.admin.base.tabber"
z_legacy_componentName="adminBaseView"
z_legacy_tabBarName="adminBaseView_tabBar"
z_legacy_tabLabel="main.admin.base.tabber"
>
<components>
<layout-reference resource="com.top_logic/admin/model/list/adminLists.layout.xml"/>
</components>
</include>
}}}
zu
{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>

<config:template-call
xmlns:config="http://www.top-logic.com/ns/config/6.0"
template="com.top_logic/legacyTabbar.template.xml"
>
<arguments
helpIDLegacy="main.admin.base.tabber"
z_legacy_componentName="adminBaseView"
z_legacy_tabBarName="adminBaseView_tabBar"
z_legacy_tabLabel="main.admin.base.tabber"
>
<components>
<layout-reference resource="com.top_logic/admin/model/list/adminLists.layout.xml"/>
</components>
</arguments>
</config:template-call>
}}}

Note: com.top_logic/legacyTabbar.template.xml ist die direkte Migration auf #25242. Die Migration auf genau die Ticket-Version würde com.top_logic/tabbar.template.xml verwenden.

• masterFrame.layout.xml auf mainTabbar.layout.xml umstellen.
  • Das masterFrame.layout.xml hatte ein untypisiertes Template materFrame.xml benutzt, wo die Property components i.a.R. benutzt wurde bspw. durch Referenzen auf die Tabs der Haupttabbar gefüllt wurde.

{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>

<include name="templates/masterFrame.xml">
<components>
<layout-reference resource="admin/index.layout.xml"/>
</components>
</include>
}}}
Jetzt existieren drei Dateien.
* masterFrame.layout.xml benutzt das untypisierte Template von templates/masterFrame.xml um das MainLayout der Anwendung zu erstellen und hat eine Referenz auf masterContent.layout.xml.
* masterContent.layout.xml benutzt das untypisierte Template von templates/masterContent.xml um zusätzlichen Inhalt hinzuzufügen bspw. eine Statusbar und hat eine Referenz auf mainTabbar.layout.xml für die Haupttabbar.
* mainTabbar.layout.xml enthält alle Tabs für die Haupttabbar als Referenzen.

masterFrame.layout.xml und masterContent.layout.xml werden aus TL geerbt und müssen i.a.R. nicht geändert bzw. überschrieben werden.
Der Referenzen für die Tabs der Haupttabbar müssen aus masterFrame.layout.xml in mainTabbar.layout.xml verschoben werden. Das heißt aus der Datei masterFrame.layout.xml
{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>

<include name="templates/masterFrame.xml">
<components>
<layout-reference resource="admin/index.layout.xml"/>
</components>
</include>
}}}
wird die Datei mainTabbar.layout.xml mit dem Inhalt
{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>

<config:template-call
xmlns:config="http://www.top-logic.com/ns/config/6.0"
template="com.top_logic/maintabbar.template.xml"
>
<arguments>
<components>
<layout-reference resource="admin/index.layout.xml"/>
</components>
</arguments>
</config:template-call>
}}}

Offene Punkte

• Neu definierte Layouts in der Datenbank (layout_configurations) speichern, statt unter WEB-INF/layouts/0f5e4de8-138d-4170-8c85-ce4b99425de2.layout.xml
• Dynamisch instanziierbare Layout-Templates sollten Dateinamen *.template.xml heißen (statt zwanghaft in einem (Unter-)Ordner dynamic liegen zu müssen).
• Veröffentlichen- und Layouts-Exportieren-Buttons nur im Design-Mode anzeigen.
• ~~Sichtem im Top-Level-Tab können nicht hinzugefügt werden. ~~
• Bei konfigurierten Komponenten muss die Konfiguration nach dem Klick auf "ok" auch wieder bearbeitet werden können (und möglicherweise wieder gelöscht werden können).
• Besser Anzahl von Unterkomponenten eingeben bei neuem Layout - oder jedes Layout benötigt Parameter - vielleicht ist das auch so, weil man wohl mindestens die Default-Größen eingaben muss!. Keine Booleans als Text-Eingabe, ...:

• Komplizierte Parameter benötigen Dokumentation, sonst ist es schlicht unmöglich die GUI zu bedienen, die Reihenfolge von Parametern ist wichtig - zuerst die Baum-Wurzel, dann die Kinder - sonst bekommt man einen Knoten im Kopf z.B.:
  • Dokumentation aus JavaDoc wird genutzt, muss von Fall zu Fall noch ergänzte oder verbessert werden.

• Tab-Konfiguration nicht an allen Tabs möglich, Konfigurationsknopf wird aber trotzdem angezeigt.

• Für Hauptreiter sollte man auch ein Icon Konfigurieren können (für die Anzeige im Sidebar Layout)
  • Icons können jetzt für alle Tabs konfiguriert werden.

• Anlage einer Grid-Tabelle ohne Model Builder ergibt nichts sagende Fehlermeldung und Error - Logmeldungen: Kann die Fehlerbehandlung verbessert werden? Bei einer Grid, nach Angabe des Typs - könnte nicht auch die Expression all(`Typ`) als Default Model Builder genutzt werden?
  • Expression ist jetzt mandatory. Default wäre zu aufwendig / unklar wie zu realisieren.

• In Tabbars einzelne Tabs nur anzeigen, während die Tabbar erstellt wird.
• Crash, wenn man einen offenen Dialog bearbeitet (Sicht bearbeiten aus dem top-level Burger-Menü). Das Ersetzen des Dialogs funktioniert noch nicht richtig. Im Anhang befindet sich ein "Patch" der den Dialog ersetzt, aber nicht aktualisiert. Dazu muss der Dialog geschlossen und neu geöffnet werden. Desweiteren wird der Button in der Toolbar des DialogParent bei Veränderung ebenfalls nicht angepasst.
• Target-Spezifikation für ein Command-by-expression funktioniert nicht, wenn man die initial dargestellte Default-Configuation z.B. auf selection(self()) ändert.
• Spezielles Kommando für "Dialog hinzufügen".
• "Create"-Commando, das ein Objekt eines auszuwählenden Typs anlegt (Formular aus Typedefinition und Script, das das neue Objekt in seine Umgebung einfügt).
• Doppelte Kommandos für Bearbeitung der Komponenten teilweise doppelt.
• Skripting von GUI-Änderungen hängt, wenn man es im Scriptrecorder abspielt.
• Wie schließt man einen Dialog aus einem konfigurierten Kommando?

Test

• Scripts com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/**