• If I reconfigure a dialog afterwards and use the red "X" at the very top right to remove the entire form, I cannot log in to the application afterwards.
  • The "X" for the entire form should probably never be displayed. Neither when editing nor when creating. Neither for dialogs nor for other views.
  • It must not happen that the customer can no longer log into his application and the only solution is "throw everything away". No matter by what error it comes to that. Even if this does not affect the root account but only one of many accounts: If he has laboriously configured his application for weeks, and then the only solution to fix the login is "throw away the work of the last weeks", he will not shop with us anymore.
• When I click on "reset layout configuration", a warning comes up in the log: Dropped dangling DBContext: DBContext[person:1] M 1 N 0 R 0 Here is the abbreviated 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.
• I get a NullPointerException in the following scenario and opening the dialog fails:
• Note: Do not log out in between.
• Create a new tab.
• Create a new table in it.
• Add a dialog afterwards. So not directly when creating the table.
• Open dialog.
• A NullPointerException is thrown.
• LayoutComponent.getWindow() returns null.
• This causes LayoutComponent.getDialogSupport() to fail.
• The component is the TableComponent.
• ~~When I configure the main tabs, there is another tab "Permissions" in the options. If I select that, 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 is nothing to do about it, because the legacy layout is still included in quite a lot of applications.
• There is now a configuration tl:LayoutEditorConfig where you can explicitly define a set of layouts that are not available to e.g. create new tabs.
• If I specify a "command to open dialog", I have to think of an ID. This must not collide with an existing ID, otherwise there will probably be problems. But there is no constraint for this.
• This is quite difficult to implement (I don't know how) - for relatively little benefit.
• When I add a dialog without creating a "command to open dialog", the button to open the dialog has the icon for "missing an icon here": <?>.
• Dialog opener is now selected by default. But if you don't specify an icon, then you don't have an icon, I guess that's normal.
• If a user puts in an infinite loop in a TL script expression by mistake (or on purpose), is that caught somewhere via a timeout, or is the server thread then busy until the application is restarted at some point? If we don't prevent this, anyone who is allowed to customize a view can drive the server into overload: All it takes is to reload the corresponding page often enough, because the server seems to be "not responding" (because it's stuck in the infinite loop).
• Yes - if you're clever about it, you can probably get an infinite loop to work. That's a separate ticket.
• Releasing the layout failed with a NullPointerException. Since this was already tested by Sven that it works in principle, it is probably related to the specific layout: In the main tab bar is a new tab with a nameless table representing DemoTypes:DemoTypes.All, and a nameless form that has as model the selection of the component. I can reproduce it, report back to me if necessary.

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 and icon, quite a few consequential errors occur. A tl:constraint must prevent this.
• Tab name is mandatory.
• If F5 is pressed in a view with several single-line TL script fields, several JavaScript errors are written to the log. About 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' [...])
- From time to time this also happens when I want to close the dialog by pressing ESC. Then the dialog is still open. But with ESC I cannot reproduce this stably.
* Fixed.

• When configuring for example trees, if not all TL script expressions are filled and I press "Ok", exceptions and errors occur in the log. Probably depending on the amount of filled expressions other errors. 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 among other things these views have not yet been converted to typed templates. The "Add Tab" command is now only executable if the tabbar is instantiated from a typed template.
• Dialogs can be created but not edited. Dialogs are not respected when replacing components. In addition, changes in the configuration of the dialog, e.g. its icon or name, are not applied because the DialogParent is not updated.
  • Dialogs can now be edited and replaced. The update is performed directly after command execution.
• When creating an OpenHandler for a dialog, so far only the ID property is mandatory. A missing specification of resources causes missing resource ... Error messages in the log for the configured command. The same problem applies to configured button commands.
  • The label of the command to open a dialog is now mandatory.
• The "default dialog opener" as button command does not work, because among other things it is not possible to select the dialog to open at all. This results in an NPE.
  • For the standard dialog opener it is now necessary to select a (global) dialog that is to be opened.
• If one selects as ModelProvider a provider by expression for a component, this leads without further changes to this field to an error. A suitable default value, like it is used in other TLScript fields, would be a consistent solution.
  • tl:ModelProviderByExpression now has the null expression as default.
• If you execute the commands "Design form" or "Reset form" for an in-app created form, this leads to an error if the form does not have a model.
  • Since an in-app form determines its type by its model, the in-app specific form commands can only be executable if the form has a model. The corresponding tl:ExecutabilityRule has been added.
• If the type of a table is changed afterwards. The options and selection of columns must also be adjusted.
  • When changing the type of the table, the selection in the fields for the properties of the column configuration is kept. In declarative forms I don't know how to solve this problem "cleanly". A listener on the property that reacts to changes of the type can therefore not be registered. Instead there is now a constraint which checks if the selected columns are valid for the given type when the component configuration is completed.

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