• Wenn ich einen Dialog nachträglich umkonfiguriere und dabei ganz oben rechts das rote "X" nutze um das gesamte Formular zu entfernen, kann ich mich anschließend in die Anwendung nicht mehr einloggen.
  • Das "X" für das gesamte Formular darf vermutlich nie angezeigt werden. Weder beim Bearbeiten noch beim Anlegen. Weder für Dialoge noch für andere Sichten.
  • Es darf nicht passieren, dass der Kunde sich nicht mehr in seine Anwendung einloggen kann und die einzige Lösung ist "wirf alles weg". Egal durch welchen Fehler es dazu kommt. Selbst wenn das nicht den Root-Account betrifft sondern nur einen von vielen Accounts: Wenn er sich Wochenlang mühsam seine Anwendung konfiguriert hat, und dann ist die einzige Lösung um den Login zu reparieren "wirf die Arbeit der letzten Wochen weg", wird er nicht mehr bei uns einkaufen.
• Wenn ich auf "Layoutkonfiguration zurücksetzen" klicke, kommt eine Warnung im Log: Dropped dangling DBContext: DBContext[person:1] M 1 N 0 R 0 Hier der gekürzte Allocation-Stack-Trace:

[...]
 at com.top_logic.knowledge.wrap.AbstractWrapper.setReference(AbstractWrapper.java:904)
 at com.top_logic.mig.html.layout.PersistentTemplateLayoutWrapper.setPerson(PersistentTemplateLayoutWrapper.java:55)
 at com.top_logic.mig.html.layout.LayoutStorage.internalReleaseLayouts(LayoutStorage.java:805)
 at com.top_logic.mig.html.layout.LayoutStorage.releasePersistentLayouts(LayoutStorage.java:781)
 at com.top_logic.mig.html.layout.LayoutStorage.releasePersistentLayouts(LayoutStorage.java:769)
 at com.top_logic.layout.editor.commands.ReleaseLayoutConfiguration.internalHandleCommand(ReleaseLayoutConfiguration.java:65)
 at com.top_logic.tool.boundsec.ConfirmCommandHandler.handleCommand(ConfirmCommandHandler.java:46)
 at com.top_logic.tool.boundsec.CommandHandlerUtil.handleCommand(CommandHandlerUtil.java:26)
 at com.top_logic.mig.html.layout.LayoutComponent.dispatchCommand(LayoutComponent.java:3384)
 at com.top_logic.mig.html.layout.CommandDispatcher.internalDispatchCommand(CommandDispatcher.java:158)
 at com.top_logic.mig.html.layout.CommandDispatcher.internalDispatch(CommandDispatcher.java:95)
 at com.top_logic.mig.html.layout.CommandDispatcher.dispatchCommand(CommandDispatcher.java:78)
 at com.top_logic.tool.boundsec.SuspendedResult.resume(SuspendedResult.java:58)
 at com.top_logic.tool.boundsec.HandlerResult$1.executeCommand(HandlerResult.java:259)
 at com.top_logic.layout.basic.DelegatingCommandModel.internalExecuteCommand(DelegatingCommandModel.java:51)
 at com.top_logic.layout.basic.AbstractCommandModel.executeCommand(AbstractCommandModel.java:45)
 at com.top_logic.layout.basic.CommandModelAdapter.executeCommand(CommandModelAdapter.java:47)
 at com.top_logic.layout.messagebox.MessageBox$ClosingCommand.executeCommand(MessageBox.java:656)
[...]

• Gefixt.
• Ich bekomme in folgendem Szenario eine NullPointerException und das Öffnen des Dialoges scheitert:
• Hinweis: Zwischendurch nicht ausloggen.
• Neuen Tab anlegen.
• Darin eine neue Tabelle anlegen.
• Nachträglich einen Dialog hinzufügen. Also nicht direkt beim Anlegen der Tabelle.
• Dialog aufmachen.
• Es kommt eine NullPointerException.
• LayoutComponent.getWindow() liefert null.
• Dadurch schlägt LayoutComponent.getDialogSupport() fehl.
• Die Komponente ist die TableComponent.
• ~~Wenn ich die Hauptreiter konfiguriere, gibt es in den Optionen einen weiteren Reiter "Berechtigungen". Wähle ich den aus, wird eine Warnung geloggt: > Duplicate component name com.top_logic.element/admin/security/securityStructure.xml#adminRolesView_navigationTree ...~~
• Das liegt daran, dass sich ein Legacy-Layout einen Komponenten-Namen mit einem anderen Layout teilt. Da ist nichts gegen zu unternehmen, da das Legacy-Layout noch in ganz vielen Anwendungen eingebunden ist.
• Es existiert nun eine Konfiguration tl:LayoutEditorConfig wo man explizit eine Menge von Layouts festlegen kann, die nicht zur Verfügung stehen um bspw. neue Tabs anzulegen.
• Wenn ich ein "Kommando zum Dialog-Öffnen" angebe, muss ich mir eine ID ausdenken. Diese darf nicht mit einer existierenden ID kollidieren, sonst gibt es vermutlich Probleme. Aber es gibt kein Constraint dafür.
• Das ist ganz schwierig zu realisieren (ich weiß nicht wie) - für relativ wenig Nutzen.
• Wenn ich einen Dialog hinzufüge, ohne ein "Kommando zum Dialog-Öffnen" zu erstellen, hat der Knopf zum Öffnen des Dialoges das Icon für "hier fehlt ein Icon": <?>
• Dialog-Öffner ist jetzt standardmäßig ausgewählt. Wenn man aber kein Icon angibt, dann hat man kein Icon, das ist wohl normal.
• Wenn ein Nutzer in einem TL-Skript-Ausdruck aus Versehen (oder absichtlich) eine Endlosschleife einbaut, wird das irgendwo über einen Timeout abgefangen, oder ist dann der Server-Thread belegt, bis die Anwendung irgendwann neu gestartet wird? Wenn wir das nicht verhindern, kann jeder, der sich eine Sicht anpassen darf, den Server in die Überlastung treiben: Dazu muss nur die entsprechende Seite oft genug neu aufgerufen werden, weil der Server scheinbar "nicht reagiert" (weil er in der Endlosschleife hängt).
• Ja - wenn man es geschickt anstellt, bekommt man wahrscheinlich eine Endlosschleife hin. Das ist ein eigenes Ticket.
• Das Freigeben des Layouts schlug mit einer NullPointerException fehl. Da das schon vom Sven getestet wurde, dass es prinzipiell funktioniert, hängt es vermutlich mit dem konkreten Layout zusammen: In der Haupt-Reiter-Leiste ist ein neuer Reiter mit einer namenlosen Tabelle, die DemoTypes:DemoTypes.All darstellt, und ein namenloses Formular, dass als Modell die Selektion der Komponente hat. Ich kann es reproduzieren, notfalls bei mir melden.

java.lang.NullPointerException
 at com.top_logic.dob.identifier.ObjectKey$3.map(ObjectKey.java:91)
 at com.top_logic.knowledge.service.db2.expr.visit.ObjectExpressionEvaluator.visitIdentifier(ObjectExpressionEvaluator.java:235)
 at com.top_logic.knowledge.service.db2.expr.visit.ObjectExpressionEvaluator.visitIdentifier(ObjectExpressionEvaluator.java:1)
 at com.top_logic.knowledge.search.Operator.visit(Operator.java:143)
 at com.top_logic.knowledge.service.db2.expr.visit.AbstractExpressionEvaluator.visitUnaryOperation(AbstractExpressionEvaluator.java:203)

• Gefixt.
• Wenn ein Reiter ohne Name und Icon angelegt wird, kommt es zu etlichen Folgefehlern. Ein tl:Constraint muss das verhindern.
• Reiter-Namen ist mandatory.
• Wenn in einer Sicht mit mehreren einzeiligen TL-Skript-Felder F5 gedrückt wird, werden mehrere JavaScript Fehler ins Log geschrieben. Etwa eine Fehler pro TL-Skript-Feld. Getestet im Firefox.

Client-side message: Uncaught JavaScript exception (exception: 'TypeError: can't access property "layout", closestLayoutResizeElement is null', component: 'rootLayout#masterFrame' [...])
- Ab und zu passiert das auch wenn ich mittels ESC den Dialog schließen möchte. Dann ist der Dialog anschließend noch offen. Aber mit ESC kann ich das nicht stabil reproduzieren.
* Gefixt.

• Wenn beim Konfigurieren von zum Beispiel Bäumen nicht alle TL-Skript-Ausdrücke gefüllt sind und ich drücke auf "Ok", kommt es zu Exceptions und Fehlern im Log. Vermutlich je nach Menge der gefüllten Ausdrücke andere Fehler. Hier sollte es Constraints an den Feldern geben.
  • Script-Properties sind jetzt non-nullable.
• Das Hinzufügen eines neuen Reiters schlägt manchmal mit einer NullPointerException fehl. Aufgetreten ist der Fehler bei den Reitern, die auf folgenden Seiten zu finden waren:
  • Strukturen > Typendemo
  • Technische Demo > LayoutFramework
  • Security Beispiele > Security Beispieltypen
  • Das Problem ist dass u.a. diese Sichten noch nicht auf typisierte Templates umgestellt worden sind. Das "Tab hinzufügen" Kommando ist nun nur ausführbar falls die Tabbar von einem typisierten Template instantiiert wird.
• Dialoge können zwar angelegt werden, aber nicht bearbeitet werden. Beim Ersetzen von Komponenten werden Dialoge nicht respektiert. Außerdem werden Änderungen in der Konfiguration des Dialoges, bspw. sein Icon oder der Name, nicht übernommen, da der DialogParent nicht aktualisiert wird.
  • Dialoge können nun bearbeitet und ersetzt werden. Die Aktualisierung wird direkt nach Kommandoausführung durchgeführt.
• Beim Erstellen von einem OpenHandler für einen Dialog ist bisher nur die ID Property mandatory. Eine fehlende Angabe von Resourcen sorgt für missing resource .. Fehlermeldungen im Log für das konfigurierte Kommando. Das gleiche Problem trifft für konfigurierte Button Kommandos zu.
  • Das Label des Kommandos zum Öffnen eines Dialogs ist nun mandatory.
• Der "Standard-Dialog-Öffner" als Button Kommando funktioniert nicht, da u.a. es überhaupt nicht möglich ist den zu öffnenden Dialog auszuwählen. Das resultiert in eine NPE.
  • Für den Standard-Dialog-Öffner ist es nun notwendig einen (globalen) Dialog auszuwählen, der geöffnet werden soll.
• Wählt man als ModelProvider einen Provider per Ausdruck für eine Komponente aus, führt ohne weitere Änderungen an diesem Feld dies zu einem Fehler. Ein passender Default Wert, wie es bspw. in anderen TLScript-Feldern bentutzt wird, wäre eine konsistente Lösung.
  • tl:ModelProviderByExpression hat nun die Null Expression als Default.
• Führt man die Kommandos "Formular gestalten" bzw. "Formular zurücksetzen" für ein In-App erstelltes Formular aus, dann führt dies zu einem Fehler falls das Formular kein Modell besitzt.
  • Da ein In-App Formular seinen Typ über sein Modell bestimmt können die In-App spezifischen Formularkommandos nur ausführbar sein falls das Formular ein Modell besitzt. Die entsprechenden tl:ExecutabilityRule wurde ergänzt.
• Wird der Typ einer Tabelle nachträglich geändert. So müssen auch die Optionen und Auswahl der Spalten angepasst werden.
  • Bei Typ-Wechsel der Tabelle wird die Selektion in den Feldern für die Properties der Spaltenkonfiguration beibehalten. In deklarativen Formularen ist mir nicht bekannt dieses Problem "sauber" zu lösen. Einen Listener an dem Property der auf Änderungen des Typs reagiert kann folglich nicht registriert werden. Stattdessen existiert nun ein Constraint was bei abgeschlossener Komponentenkonfiguration prüft ob die ausgewählten Spalten gültig für den gegebenen Typ sind.

Test

• /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestDialogCreation.script.xml
• /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestDialogEdit.script.xml
• /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestButtonCreationByExpression.script.xml
• /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestButtonCreationForExistingDialog.script.xml