• If I reconfigure a dialog later and use the red "X" in the upper-right corner to remove the entire form, I can no longer log in to the application afterward.
  • The “X” for the entire form should probably never be displayed—neither when editing nor when creating, and neither for dialogs nor for other views.
  • It must not happen that the customer can no longer log in to their application and the only solution is “delete everything.” No matter what error causes this. Even if it doesn’t affect the root account but only one of many accounts: If a customer has spent weeks painstakingly configuring their application, and then the only way to fix the login is to “throw away the work of the past few weeks,” they will no longer buy from us.
• When I click “Reset Layout Configuration,” a warning appears in the log: Dropped dangling DBContext: DBContext[person:1] M 1 N 0 R 0 Here is the truncated 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)
[...]

• Fixed.
• In the following scenario, I get a NullPointerException and the dialog fails to open:
• Note: Do not log out in the meantime.
• Create a new tab.
• Create a new table in that tab.
• Add a dialog afterward—not immediately when creating the table.
• Open the dialog.
• A NullPointerException occurs.
• LayoutComponent.getWindow() returns null.
• As a result, LayoutComponent.getDialogSupport() fails.
• The component is the TableComponent.
• ~~When I configure the main tabs, there is another tab in the options called "Permissions." If I select it, a warning is logged: > Duplicate component name com.top_logic.element/admin/security/securityStructure.xml#adminRolesView_navigationTree ...~~
• This is because a legacy layout shares a component name with another layout. There’s nothing that can be done about this, since the legacy layout is still integrated into a great many applications.
• There is now a configuration option, `tl:LayoutEditorConfig`, where you can explicitly specify a set of layouts that are not available for creating new tabs, for example.
• When I specify a “command to open a dialog,” I have to come up with an ID. This ID must not conflict with an existing one; otherwise, there will likely be problems. But there’s no constraint for this.
• This is quite difficult to implement (I don’t know how)—and offers relatively little benefit.
• If I add a dialog without creating a “command to open the dialog,” the button to open the dialog displays the “icon missing here” icon: <?>
• The dialog opener is now selected by default. But if you don’t specify an icon, then you don’t have one—which is probably normal.
• If a user accidentally (or intentionally) creates an infinite loop in a TL script expression, is this intercepted somewhere via a timeout, or does the server thread remain occupied until the application is eventually restarted? If we don’t prevent this, anyone authorized to customize a view could overload the server: All they’d have to do is reload the relevant page often enough because the server appears to be “unresponsive” (since it’s stuck in the infinite loop).
• Yes—if you go about it skillfully, you can probably create an infinite loop. That’s a separate issue.
• Attempting to save the layout failed with a NullPointerException. Since Sven has already tested that it works in principle, the issue is likely related to the specific layout: In the main tab bar, there’s a new tab with an unnamed table displaying `DemoTypes:DemoTypes.All `, and an unnamed form that uses the component selection as its model. I can reproduce it; let me know if you need me to test it on my end.

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)

• Fixed.
• If a tab is created without a name or icon, it causes a number of subsequent errors. A tl:Constraint must prevent this.
• The tab name is mandatory.
• When F5 is pressed in a view containing multiple single-line TL script fields, multiple JavaScript errors are logged. Roughly one error per TL script field. Tested in Firefox.

Client-side message: Uncaught JavaScript exception (exception: 'TypeError: can't access property "layout", closestLayoutResizeElement is null', component: 'rootLayout#masterFrame' [...])
- This also happens occasionally when I try to close the dialog using ESC. Then the dialog remains open afterward. But I can’t reliably reproduce this with the ESC key.
* Fixed.

• When configuring trees, for example, if not all TL script expressions are populated and I click "OK," exceptions and errors appear in the log. The specific errors likely vary depending on the number of populated expressions. There should be constraints on the fields here.
  • Script properties are now non-nullable.
• Adding a new tab sometimes fails with a NullPointerException. The error occurred with the tabs found on the following pages:
  • Structures > Type Demo
  • Technical Demo > LayoutFramework
  • Security Examples > Security Example Types
  • The problem is that these views, among others, have not yet been converted to typed templates. The "Add Tab" command can now only be executed if the tab bar is instantiated from a typed template.
• Dialogs can be created, but not edited. When replacing components, dialogs are not taken into account. Additionally, changes to the dialog’s configuration—such as its icon or name—are not applied because the DialogParent is not updated.
  • Dialogs can now be edited and replaced. The update is performed immediately after the command is executed.
• When creating an OpenHandler for a dialog, only the ID property is currently mandatory. Failure to specify resources results in “missing resource” error messages in the log for the configured command. The same issue applies to configured button commands.
  • The label of the command to open a dialog is now mandatory.
• The “default dialog opener” as a button command does not work because, among other things, it is not possible at all to select the dialog to be opened. This results in an NPE.
  • For the standard dialog opener, it is now necessary to select a (global) dialog to be opened.
• If you select a provider via expression for a component as the ModelProvider, this results in an error without further changes to this field. A suitable default value, such as those used in other TLScript fields, would be a consistent solution.
  • tl:ModelProviderByExpression now has the null expression as its default.
• Executing the "Design Form" or "Reset Form" commands for a form created in-app will result in an error if the form does not have a model.
  • Since an in-app form determines its type based on its model, the in-app-specific form commands can only be executed if the form has a model. The corresponding tl:ExecutabilityRule has been added.
• If the type of a table is changed later, the options and selections for the columns must also be adjusted.
  • When the table’s type changes, the selections in the fields for the column configuration properties are retained. I am not aware of a “clean” way to solve this problem in declarative forms. Consequently, a listener that reacts to changes in the type cannot be registered on the property. Instead, there is now a constraint that checks, once the component configuration is complete, whether the selected columns are valid for the given type.

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