Hintergrund

Definiert man im Modell eine Baumstruktur, können unter bestimmten Knoten (Typen) jeweils bestimmte Unterknoten (Typen) angelegt werden. Beispiel: Unter dem Root Element nur Projekte, unter Projekten nur Teilprojekte und unter Teilprojekten nur Arbeitspakete.

Wenn man das Strukturmodell als Ableitung der Basisklasse "Structured Element Container" aufbaut und dann in der Baumdarstellung den "Dialog zur Objektanlage" nutzt, gibt es mit der Option "passende Strukturknoten" einen Automatismus, der die jeweils zum selektierten Element passenden Kind-Typen für die Objektanlage anbietet. Alternativ kann man über die Annotation "dynamische Typoptionen" die passenden Kind-Typen für das selektierte Element via Expression ausrechnen.

Problem

Wird die Baumstruktur als Tree-Grid dargestellt, gibt es alternativ zum "Dialog zur Objektanlage" die Funktion "Neue Zeile". Hier gibt es weder die Möglichkeit den Anlagetyp dynamisch zu berechnen, noch automatisch als "passende Strukturknoten" zu ermitteln. Es muss immer ein konkreter Anlagetyp angegeben werden. Wird ein Abstrakter Typ angegeben, werden dem Anwender alle konkreten Subtypen zur Auswahl angeboten. Modellregeln, die definieren, welche Kind-Typen unter welchem Strukturknoten angelegt werden dürfen, können so nicht berücksichtigt werden.

Damit ist die Funktion "neue Zeile" in einer Tree-Grid zur Pflege von Strukturen in vielen Fällen unbrauchbar.

Workaround

Man kann mehrere Kommandos "Neue Zeile" zur expliziten Anlage spezifischer Kind-Typen definieren und diese Kommandos dann über deren Ausführbarkeitsregel in Abhängigkeit vom selektierten Element einblenden / ausblenden bzw. aktivieren / deaktivieren. Beispielsweise wären "Neues Projekt" und "Neues Teilprojekt" dann separate Buttons von denen der erste nur aktiv ist, wenn der Root-Knoten selektiert wird und der zweite nur aktiv wäre, wenn ein Projekt-Knoten gewählt wird.

Umsetzung

Das Kommando "Neue Zeile" wird Table- und Tree-Grids jetzt bei der Erstellung der Sicht hinzugefügt. Dazu wurde es in die entsprechenden .template.xml Dateien eingetragen.

Code Migration

1. Die in-app konfigurierten Layouts in der Datenbank werden automatisch beim Applikationsstart migriert.

2. Layout XMLs im Workspace können über folgenden Aufruf migriert werden (im Verzeichnis des jeweiligen Applikationsmoduls):

mvn exec:java@migrate-ticket -Dtl.migrationClass=com.top_logic.model.search.migrate.ticket27604.UpgradeGridCreateHandlerByExpression27604

3. Nur für Legacy-Konfigurationen des tl:GridCreateHandlerByExpression in der Anwendungskonfiguration:
   • Wert des Attributes createType notieren und das Attribut löschen.
   • Dafür Folgendes XML Tag einfügen:

{{{#!xml <type-options class="com.top_logic.element.layout.create.ConstantCreateTypeOptions"

include-subtypes="true"
type="HIER CREATE_TYPE EINFÜGEN"

/> }}}

• Prüfen, ob include-subtypes dem gewünschten Verhalten entspricht.

Anzeige des Type Choosers

Die Optionen typeChooser des tl:AbstractGridCreateHandler und include-subtypes von tl:ConstantCreateTypeOptions muss in den Layout Dateien überprüft werden. Das alte Verhalten ist nicht mehr möglich und musste daher geändert werden:

Bisher wurde der Wert von typeChooser ignoriert, wenn "der Typ" abstrakt war. In dem Fall wurde immer die Type Chooser angezeigt. Nur wenn "der Typ" konkrete Typen war, wurde diese Option beachtet.

Es gibt aber nicht mehr "den Typ". Bisher war das der Obertyp, dessen Subtypen ausgerechnet und angeboten wurden. Jetzt ist der Algorithmus zur Berechnung der angebotenen Typen abstrakt. Es gibt daher nicht mehr in allen Fällen "den Typen" aus dem sich der Rest berechnet. Das ist jetzt in tl:CreateTypeOptions gekapselt. Daher macht die alte Bedeutung der Option keinen Sinn mehr.

Die neue Bedeutung ist: Wenn mehrere mögliche Typen ausgerechnet werden, aber es einen default Typ gibt, soll der Nutzer dann einen der anderen Typen auswählen können? Ist die Option false, wird in dem Fall immer der Default Typ genommen, ohne dass der Nutzer das ändern kann. Das entspricht ungefähr dem alten Verhalten, dass der Nutzer den konkreten Obertypen nehmen muss, auch wenn es Subtypen gibt.

Die Verwendungen der Optionen typeChooser und include-subtypes müssen also zusammen daraufhin überprüft werden, ob ihre Sicht sich wie gewünscht verhält.

Test

• Eine neue Tree-Grid In-App konfigurieren.
  • Der Knopf "Neue Zeile" muss direkt Teil der neuen Sicht sein und funktionieren.
• Eine flache Grid In-App konfigurieren. (Also nicht-Tree-Grid)
  • Dito.