Sichten bearbeiten

• Ich hätte gerne den "Zurücksetzen" Button für den Selektionsdialog der Reiter. Wenn ich zum Beispiel im Demo eine Sicht entferne, kommen etliche neue in den Optionen hinzu. Ich weiß dadurch nicht mehr, welche davon ich auswählen muss, damit es so wie vorher ist.
  • Der Knopf "Layoutkonfiguration zurücksetzen" im Burger-Menü ist ausgegraut, falls der dafür zuständig sein soll.
  • Problem gefixt, der Zurücksetzen-Button ist jetzt dann aktiv, wenn es eine Konfiguration gibt und nicht umgekehrt.
• Für das Einfügen eines neuen Reiters gibt es extra einen Knopf. Der öffnet aber zuerst einen Dialog, in dem genau ein Auswahlfeld mit genau einer Option "Tab" angezeigt wird. Diese Option ist auch nicht vorausgewählt, sondern muss erst ausgewählt werden. Kann der ganze Dialog nicht weggelassen werden, wenn schon der Knopf genau dafür da ist einen Tab anzulegen?
  • Das Dialog-Erstellen ist genauso seltsam wie das Tab-Erstellen.
  • Gefixt, solange es nur eine Option gibt (abhängig von den verfügbaren Templates) wird kein Auswahldialog angezeigt.
• Der Dialog um einen neuen Tab zu konfigurieren, ist viel zu groß für seine drei Eingabefelder.
  • Ja, aber das wäre zu aufwendig anzupassen - das Template müsste auch noch die Dialog-Größe bestimmen können.
• ~~Wenn ein neuer Reiter angelegt wird, wäre es nett, wenn der direkt ausgewählt wird. Denn vermutlich möchte man ihn im nächsten Schritt mit Inhalt füllen. ~~
  • Neu angelegete Tabs werden selektiert.
• Ein neu angelegete Fachobjekt soll direkt selektiert werden.
• Beim Konfigurieren zum Beispiel einer Tabellen-Sicht werden alle Typen im System in einem großen Drop-Down-Field angeboten. Ich hätte gerne etwas praktischeres. Sowas wie beim Anlegen von neuen Typen für die Auswahl der Obertypen. Nur das "Search as you type" mit qualifizierten Namen funktioniert. Und das die internen Typen weggefiltert werden. Die Modellbasierten Suche hat für das Filtern schon Funktionalität und eine fertige Heuristik.
  • Beim Auswählen des Listenelementtyps wird nun ein Selection Dialog geöffnet, wo nun mit Hilfe von "Search as you type" der voll qualifizierte Name eines Typs eingegeben werden kann. Die Typ Optionen sind bereits vorgefiltert sodass interne Typen u.a. nicht ausgewählt werden können.
• Beim Klicken auf "Layout exportieren" kommt ein Dialog mit dem Titel "Bitte bestätigen" und dem Inhalt: "Sind Sie sicher, dass Sie diese Aktion ausführen wollen?" Das verunsichert mich. Warum sollte ich das //nicht// machen wollen? Hier sollte erklärt werden, was das für Konsequenzen hat, was dagegen spricht und was dafür.
  • Meldung beim Layout-Exportieren verbessert.
• Bei manchen Reitern ist der Knopf "Sicht löschen" ausgegraut. Begründung: "Komponente ist nicht von einem typisierten Template instantiiert." Aber wenn ich statt dessen "Reiter konfigurieren" klicke, kann ich die Sicht entfernen. Das ist inkonsistent. Das lässt sich zum Beispiel im Demo mit dem Reiter Suche reproduzieren.
  • "Reiter konfigurieren" und "Sicht löschen" führen nicht die gleiche Operation durch. "Reiter konfigurieren" konfiguriert, wie der Name bereits andeutet, die Reiter bzw. Tabs. D.h. in der Tabbar Konfiguration werden tl:LayoutReference geordnet, hinzugefügt oder entfernt. Das Layout der Reiter hingegen wird nicht weiter verändert. "Sicht löschen" hingegen entfernt das komplette Layout dieser Sicht, also auch der Teil-Sichten. Konkret wird das Layout aus der Datenbank entfernt. Das Kommando sollte jedoch nur ausführbar sein wenn es keine Referenzen oder Komponentenkanäle gibt, die zu (Slave-) Komponenten außerhalb der zu löschen Sicht, gelinkt sind. Diesen Unterschied müsste man dem Nutzer verdeutlichen.
• Bei manche Sichten ist der Knopf "Sicht löschen" aktiv. Aber wenn er gedrückt wird, kommt eine Fehlermeldung: "Komponente konnte nicht entfernt werden, da weitere, nicht zu löschende, Komponenten auf diese Komponente Referenzen besitzen." Aber wenn ich statt dessen "Reiter konfigurieren" klicke, kann ich die Sicht entfernen. Das lässt sich zum Beispiel im Demo mit dem Reiter "Tabellen" reproduzieren. Das ist in zweierlei Hinsicht inkonsistent:
  • Entweder die Sicht kann entfernt werden oder sie kann nicht entfernt werden. Wenn sie nicht entfernt werden kann, sollte sie in der Auswahlliste entsprechend markiert werden. Wir können doch Optionen als "nicht abwählbar" auszeichnen.
  • Wenn eine Sicht nicht entfernt werden kann, sollte der Knopf ausgegraut sein, wie im Fall: "Komponente ist nicht von einem typisierten Template instantiiert."
• ~~ In einigen Sichten lassen sich keine Reiter hinzufügen. Statt dessen wird eine Exception geworfen, wenn man im Reiter-Anlage-Dialog auf Ok klickt. Der Knopf zum Löschen der dortigen Reiter ist auch entsprechend ausgegraut. Das lässt sich zum Beispiel im Demo reproduzieren, wenn neben "Strukturen -> Typendemo -> Typendemo" ein Reiter eingefügt werden soll. Zumindest sollte der Knopf ausgegraut sein, genauso wie der Knopf zum Löschen von Reitern. ~~
  • Ist durch eine Änderung durch Ticket #25095 bereits gelöst indem das "Tab hinzufügen" Kommando nur ausführbar ist falls die Tabbar von einem typisierten Template instantiiert wird.
• Neue Tabellen sind initial nicht sortiert, obwohl sie initial eine Namensspalte haben. Getestet mit einer Tabelle für DemoTypes:DemoTypes.All.
  • Es wird nach der ID-Spalte initial sortiert.
• Wenn ich eine Komponente nachträglich umkonfiguriere, wird mir als Quelle für das Modell auch die eigene Komponente angegeben. Das ist nie sinnvoll, glaube ich. Falls sich das nicht unterbinden lässt, müssen wir zumindest testen, ob das zu Endlosschleifen führt.
• Wenn ich für Sichten keinen Namen eingebe, und mich in einer anderen Sicht mit dem Modell auf diese beziehen möchte, wird sie mittels ihres qualifierten, generierten Namens angezeigt: 7616d4b7-ea88-4ba5-9a39-cc1aa1b763af.layout.xml#Table. Solange das eindeutig ist, wäre der letzte Teil "Table" deutlich besser. Und wenn das nicht eindeutig ist, hilft der generierte Name auch nicht weiter. Ein stabiler Zähler ("Tabelle 2") wäre deutlich Nutzerfreundlicher und funktioniert bei Auswahl mittels "Versuch und Irrtum" genauso gut.
  • Namen für Sichten sind jetzt verpflichtend.
• Bei der Auswahl des Modells gibt es unter anderem "-----", "Kein Modell" und "Komponente -> -----". Da es praktisch keinen Unterschied macht, verwirrt das nur unnötig.
  • Im Idealfall besteht "----" nicht als Option im Burger-Menü einer tl:ModelSpec Property und "Kein Modell", also tl:ModelSpec$Null, ist initial ausgewählt. In dieser Form ist das nicht leicht umsetzbar. Entweder man markiert die Property als tl:Mandatory, dann kann jedoch keine Option initial ausgewählt werden (in diesem Fall ist Provider by Expression initial ausgewählt) oder man markiert die Property mit tl:NonNullable und setzt einen tl:ItemDefault. Jedoch kommt es dann zum Konflikt mit dem tl:ModelSpec$Format. tl:ModelSpec$Null wird zu null() serialisiert und das wiederum zum Default-Wert, also null, deserialisiert. Da die Property tl:NonNullable ist, ergibt das einen Fehler.
• Nach dem Anlegen einer neuen Formular-Sicht möchte ich gerne das Formular für diese Sicht definieren. Es gibt keinen Knopf dazu. Und niemand errät, dass das im Reiter "Administration -> Basisadministration -> Attribute -> Eigenschaften" versteckt ist: Hier jetzt noch in den Bearbeiten-Modus schalten, die richtige Anpassung auswählen, wissen, dass das Icon ein Button ist, und schon bin ich da. Ich verstehe die Logik dahinter, dass ein Formular für einen Typ definiert wird. Und das die Sicht ist um Typen zu Bearbeiten. Und die Formular-Definition als Annotation am Typ gespeichert wird. Aber das ist für einen Nutzer, der gerade seine Sicht baut, alles andere als intuitiv.
  • Die Sicht der Formulare kann nun lokal bearbeitet werden. Dazu existiert im typisierten Template für Formulare nun eine weitere Property vom Typ tl:FormDefinition. Für jede tl:FormComponent, die von einem typisierten Template instantiiert wird, existiert ein Kommando um die zugrundeliegende tl:FormDefinition zu bearbeiten.
  • Das der Reiter um "Klassen" zu bearbeiten, "Attribute" heißt, ist auch nicht intuitiv. Historisch gewachsen, aber heutzutage leider falsch. (Wenn das geändert wird, müssen Tests angepasst werden.)
• Die Parameter, die TL-Skript-Ausdrücke als Werte haben, brauchen alle Dokumentation und am besten Beispiele für den häufigsten Fall. Was weiß ich (bzw. der Kunde) , was ich in "Oberflächenmodell" bei der Konfiguration eines Baumes eintragen soll. Da wir alle schon etliche Tabellen und Bäume definiert haben, ist das für uns vielleicht alles klar und offensichtlich. Aber nicht für einen Kunden.
  • Und auch für die anderen Parameter sollte die Dokumentation gegengelesen werden. Der Tooltip für die Checkbox "Knotenexpansion" lautet zum Beispiel: "Ob es möglich ist einen bestimmten Baumknoten zu expandieren." Welchen "bestimmten Baumknoten"? Muss ich das irgendwo definieren? Wo? Und wieso sollte ich das abschalten wollen? Dafür gibt es doch die Funktion, die die Kinder-Knoten ausrechnet. Die muss dann angepasst werden, wenn bestimmte Knoten keine Kinder haben sollen, oder? Oder schaltet diese Checkbbox das generell ab, dass Knoten expandiert werden können? Aber dort steht "einen bestimmten Baumknoten". Und das macht in einem Baum auch keinen Sinn. Dann sehe ich nur noch eine Ebene. Oder ist dann immer alles aufgeklappt? Das verwirrt mich total. Obwohl ich schon ein paar Bäume in Top-Logic gebaut habe.
• Wenn ich eine neue, leere Tab-Bar konfiguriere, wird als Inhalt "Zugriff wurde verweigert" angezeigt. Passender wäre zum Beispiel "Kein Inhalt". Vermutlich war der Text bisher zutreffend, da dieser Zustand nur dann vorkam, wenn alle Tabs aufgrund der Berechtigung ausgeblendet waren. Aber in diesem neuen Kontext ist das verwirrend.
  • Meldung bei Tabbar ohne Tabs verbessert.
• Ich kann für Tabs und Tab-Bars immer Icons auswählen, die aber anscheinend nie angezeigt werden. Eventuell handelt es sich um die Icons, die bisher in der Toolbar-Zeile angezeigt werden. Aber dort kann ich als Nutzer sowieso keine Tabs hinzufügen, oder?
  • Tooltip mit Erklärung ergänzt.
• Die Attribute im Formular-Editor sind Case-Sensitive sortiert. Das ist nicht intuitiv.
  • Attribute im Formular-Editor werden nun case insensitive sortiert.
• In Tabellen und in Grids gibt es unterschiedliche Arten, wie der dargestellte Typ dargestellt wird. In Tabellen per qualifiziertem Namen, wobei aus einer flachen Liste ausgewählt wird. Und in Grids per Label mit einer baumartigen Darstellung der Typen.
  • Einheitliche Darstellung für die Auswahl des Typs einer Tabelle oder Grid.
• In Tabellen können als "Listenelementtyp" Assoziationen ausgewählt werden. Das ist vermutlich falsch. Falls es hingegen richtig ist, muss "Elemente der Liste" das aber auch erlauben, was derzeit nicht der Fall ist.
• In Grids ist die Option "Standardspalten" mandatory. In Tabellen existiert sie überhaupt nicht.
  • Ebenfalls in Tabellen nun mandatory.
• Wenn ich eine Grid für DemoTypes:DemoTypes.All konfiguriere, werden mir zwei Spalten angeboten. Eine davon wird als "Elternelement" angezeigt, solange ich die Sicht konfiguriere. Aber in der fertigen Grid dann als [layout.element.grid.Grid.parent]. In beiden Fällen sollen die gleichen Namen angezeigt werden.
  • Das parent Attribut wurde mit Hilfe der tl:TLVisibility Annotation als HIDDEN markiert. Attribute, die nicht sichtbar sind, stehen nun nicht mehr für die Auswahl der Spalten in Grids und Tabellen zur Verfügung.
• ~~In Grids wird mir für DemoTypes:DemoTypes.All die Spalte "Elternelement" angeboten. In Tabellen gibt es diese Spalte nicht. ~~
  • Beim Erstellen von Tabellen kann man nun ebenfalls Spalten, die sichtbar sein sollen, konfigurieren.
• Wenn ich eine Grid für den Typ DemoTypes:DemoTypes.All anlege, bringt diese einen Anlagedialog mit.
  • Der lässt mich den anzulegenden Typ auswählen. Dort sind alle lokalen C-Typen enthalten, alle mit dem Namen "Demo C". Entweder die müssen weg, oder sie brauchen Labels mit denen ich sie unterscheiden kann.
    • Lokale Typen erhalten als Prefix das Label des tl:TLScope.
  • Ich kann das Elternelement nicht setzen. Das ist für StructuredElements ungünstig, weil sie dann kein Teil des Baumes sind. Damit kommen eventuell nicht alle Sichten klar. Wenn ich zum Beispiel ein Goto dorthin mache, aber die Default-Sicht zeigt einen Baum neben dem Formular an, und der Baum versucht einen Pfad zu Root zu berechnen, könnte das zu Problemen führen. Technisch gesehen liegt das daran, dass das parent Attribut sich aus dem children Attribut berechnet. Vermutlich wäre es besser, für StructuredElements einen anderen Anlagedialog zu benutzen, in dem der Parent ausgewählt werden muss.
• Wenn nachträglich das Layout bearbeitet wird, sollten dort die Namen / Titel der Sichten verwendet werden, statt "Layout-Referenzkomponente" für alle Elemente.
  • tl:LayoutReference hat nun die zusätzliche Property getTargetLabel welche mit dem titleKey oder dem lokalen Namen der Zielkomponente als Fallback übereinstimmt. Statt "Layout-Referenzkomponente" wird nun das Label der Wurzelkomponente des Zieles der Referenz angezeigt.

Modell bearbeiten

• Wenn der Nutzer in der Administration eine neue Referenz anlegt, muss er auswählen "Ob die Navigation in dieser Referenz effizient ist". Da weiß ich selbst als Entwickler nicht, was das System von mir möchte.
  • Hierbei handelt es sich um die Dokumentation von EndAspect#canNavigate. Die Dokumentation wurde entsprechend ergänzt.

Eingabe von TL-Skript-Ausdrücken

• Bei der Eingabe (einzeiliger) TL-Skript-Ausdrücke kann man CTRL SPACE drücken, um Unterstützung zu bekommen. Es wird aber nicht darauf hingewiesen. Und das wird kein Kunde raten. Und ohne diese Unterstützung wird kein Kunde etwas richtiges eingeben können.
• Das nach dem Namen des Modules ein ":" als Trenner eingegeben werden muss, und nach dem Typ-Namen ein "#" steht nirgends und es gibt auch keine Unterstützung dafür.
• Genauso bei der Syntax für Lambda-Ausdrücke.
• Folgende Fehlermeldung sieht nicht richtig aus. Warum taucht das == dort zweimal auf?
  • 
  • Die Fehlermeldung hilft mir nicht weiter. Ich musste Sven fragen.
  • Die Fehlermeldung stammt direkt aus JavaCC - er beschreibt ein Token immer durch seinen Namen und seine Zeichen, bei == ist beides gleich. Es ist nicht möglich (???) die Fehlermeldung zu verbessern ohne JavaCC zu verbessern. Die Fehlermeldung sagt, dass statt == das Token (` erwartet wird. An dieser Stelle liegt das daran, dass Du das `$ vor dem Variablen-Namen model vergessen hast. Das ist ganz schwierig in einer automatisch generierten Fehlermeldung aus einer Grammatik zu erzeugen, da der Compiler ja nicht wissen konnte, was Du hinschreiben wolltest.
• In einzeiligen TL-Skript-Felder wird ein Tab nicht als "Feld wechseln" interpretiert, sondern als "Tab einfügen". Das ist nervig, wenn ich Tabellen konfiguriere und dabei nicht durch die Felder durchtabben kann.
  • Shift-Tab macht gar nichts, sollte aber rückwärts tabben.
  • Das "Tab" und "Shift-Tab" Key-Binding ist nun im ACE-CodeEditor deaktiviert.
• In TL-Skript-Feldern gibt es für Singletons von Modulen (DemoTypes#Root) keine Unterstützung bei der Eingabe. (STRG SPACE)
  • Singletons von Modulen werden nun mit Hilfe der Autovervollständigung unterstützt.

Test

• /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestReferenceLabelsInsideLayouts.script.xml
• /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestTableCreation.script.xml
• /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestGridCreation.script.xml
• Erstelle eine In-App Tabelle vom Typ DemoTypes:DemoTypes.All. Als Auswahl für die ID- und die sichtbaren Spalten darf parent nicht zur Verfügung stehen, da es per tl:TLVisibility als Hidden markiert ist.
• Prüfe in einem beliebigen TLScript-Ausdrucksfeld (bspw. in der modellbasierten Suche) ob eine Autovervollständigung für Modul Singletons angeboten wird. Tippe dazu bspw. DemoTypes# ein und prüfe die Vorschläge, oder drücke explizit CTRL-SPACE um dir die Vorschläge anzeigen zu lassen. DemoTypes#ROOT sollte als Vorschlag angezeigt werden.
• Prüfe ob du eine lokale Formularsicht anlegen kannst. Eine Tabelle mit entsprechendem Formular kann einfach über das Script /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestFormCreation.script.xml automatisiert erstellt werden (nur bis zum Punkt "Tabelle erstellen" einschließlich). Anschließend kann im Burger-Menü des Formulars ein (lokales) Formular erstellt bzw. zurückgesetzt werden. Beide Funktionalitäten sollten das Formular direkt nach Bestätigung aktualisieren.