Edit Views

• I’d like to have a “Reset” button for the tab selection dialog. For example, when I remove a view in the demo, several new ones are added to the options. This makes it hard for me to know which ones to select to restore the view to its previous state.
  • The “Reset Layout Configuration” button in the burger menu is grayed out—if that’s supposed to be the one to use.
  • Problem fixed—the Reset button is now active when a configuration exists, and not the other way around.
• There’s a separate button for inserting a new tab. However, it first opens a dialog that displays exactly one drop-down menu with exactly one option: “Tab.” This option isn’t preselected either; you have to select it first. Can’t the entire dialog be omitted since the button is specifically there to create a tab?
  • The dialog creation process is just as strange as the tab creation process.
  • Fixed: As long as there is only one option (depending on the available templates), no selection dialog is displayed.
• The dialog for configuring a new tab is much too large for its three input fields.
  • Yes, but that would be too much work to implement—the template would also need to be able to determine the dialog size.
• ~~When a new tab is created, it would be nice if it were selected right away. After all, you’ll probably want to fill it with content in the next step. ~~
  • Newly created tabs are selected.
• A newly created business object should be selected immediately.
• When configuring a table view, for example, all types in the system are listed in a large drop-down field. I’d prefer something more practical. Something similar to when creating new types for selecting supertypes. Only the “Search as you type” feature with fully qualified names works. And the internal types are filtered out. The model-based search already has functionality and a ready-made heuristic for filtering.
  • When selecting the list element type, a selection dialog now opens where you can enter the fully qualified name of a type using “Search as you type.” The type options are already pre-filtered so that internal types, among others, cannot be selected.
• Clicking “Export Layout” brings up a dialog titled “Please Confirm” with the message: “Are you sure you want to perform this action?” This makes me uneasy. Why would I //not// want to do this? There should be an explanation here of the consequences, the arguments against it, and the arguments in favor of it.
  • Improved message when exporting layouts.
• On some tabs, the “Delete View” button is grayed out. Reason: “Component is not instantiated from a typed template.” But if I click “Configure Tabs” instead, I can remove the view. This is inconsistent. This can be reproduced, for example, in the demo with the Search tab.
  • "Configure Tab" and "Delete View" do not perform the same operation. "Configure Tab," as the name suggests, configures the tabs. That is, in the tab bar configuration, tl:LayoutReference objects are organized, added, or removed. The layout of the tabs, however, is not otherwise changed. “Delete View,” on the other hand, removes the entire layout of this view, including its subviews. Specifically, the layout is removed from the database. However, this command should only be executable if there are no references or component channels linked to (slave) components outside the view to be deleted. This distinction should be made clear to the user.
• For some views, the “Delete View” button is active. But when it is clicked, an error message appears: “The component could not be removed because other components that cannot be deleted have references to this component.” But if I click “Configure Tab” instead, I can remove the view. This can be reproduced, for example, in the demo using the “Tables” tab. This is inconsistent in two ways:
  • Either the view can be removed or it cannot. If it cannot be removed, it should be marked accordingly in the selection list. After all, we can mark options as “unselectable.”
  • If a view cannot be removed, the button should be grayed out, as in the case: “Component is not instantiated from a typed template.”
• ~~ In some views, tabs cannot be added. Instead, an exception is thrown when you click OK in the Add Tab dialog. The button to delete tabs there is also grayed out accordingly. This can be reproduced, for example, in the demo when attempting to insert a tab next to “Structures -> Type Demo -> Type Demo.” At the very least, the button should be grayed out, just like the button for deleting tabs. ~~
  • This has already been resolved by a change in Ticket #25095, which ensures that the “Add Tab” command is only executable if the tab bar is instantiated from a typed template.
• New tables are not sorted initially, even though they initially have a name column. Tested with a table for DemoTypes:DemoTypes.All.
  • They are initially sorted by the ID column.
• If I reconfigure a component later, the component itself is also specified as the source for the model. I don’t think that ever makes sense. If this can’t be prevented, we must at least test whether it leads to infinite loops.
• If I don’t enter a name for a view and want to reference it in another view using the model, it is displayed using its qualified, generated name: 7616d4b7-ea88-4ba5-9a39-cc1aa1b763af.layout.xml#Table. As long as that’s unique, the last part, “Table,” would be much better. And if it’s not unique, the generated name doesn’t help either. A consistent counter (“Table 2”) would be much more user-friendly and works just as well when selecting via “trial and error.”
  • Names for views are now required.
• When selecting the model, the options include “-----,” “No Model,” and “Component -> -----.” Since there’s practically no difference, this just causes unnecessary confusion.
  • Ideally, “----” should not be an option in the burger menu of a tl:ModelSpec property, and “No Model”—i.e., tl:ModelSpec$Null—should be selected by default. This is not easy to implement in this form. Either you mark the property as tl:Mandatory—in which case, however, no option can be selected by default (in this case, “Provider by Expression” is selected by default)—or you mark the property with tl:NonNullable and set a tl:ItemDefault. However, this then causes a conflict with tl:ModelSpec$Format. tl:ModelSpec$Null is serialized to null(), and that, in turn, is deserialized to the default value—i.e., null. Since the property is tl:NonNullable, this results in an error.
• After creating a new form view, I’d like to define the form for that view. There’s no button for this. And no one would guess that it’s hidden in the “Administration -> Basic Administration -> Attributes -> Properties” tab: Now I just need to switch to edit mode here, select the correct setting, realize that the icon is a button, and I’m there. I understand the logic behind defining a form for a type, that the view is for editing types, and that the form definition is stored as an annotation on the type. But for a user who is in the process of building their view, this is anything but intuitive.
  • Form views can now be edited locally. To this end, the typed template for forms now includes an additional property of type tl:FormDefinition. For every tl:FormComponent instantiated by a typed template, there is a command to edit the underlying tl:FormDefinition.
  • The fact that the tab for editing “classes” is labeled “Attributes” is also not intuitive. It’s a historical legacy, but unfortunately incorrect today. (If this is changed, tests will need to be updated.)
• The parameters that have TL script expressions as values all need documentation and, ideally, examples for the most common use cases. How am I (or the customer) supposed to know what to enter in “Surface Model” when configuring a tree? Since we’ve all already defined quite a few tables and trees, this might all be clear and obvious to us. But not to a customer.
  • And the documentation for the other parameters should also be reviewed. For example, the tooltip for the “Node Expansion” checkbox reads: “Whether it is possible to expand a specific tree node.” Which “specific tree node”? Do I have to define that somewhere? Where? And why would I want to disable that? Isn’t that what the function for calculating child nodes is for? That function needs to be adjusted if certain nodes aren’t supposed to have children, right? Or does this checkbox generally disable the ability to expand nodes? But it says “a specific tree node.” And that doesn’t make sense in a tree either. Then I’d only see one level. Or would everything always be expanded? This is totally confusing me. Even though I’ve already built a few trees in Top-Logic.
• When I configure a new, empty tab bar, the content displayed is “Access Denied.” A more appropriate message would be, for example, “No content.” Presumably, the text was accurate before, since this state only occurred when all tabs were hidden due to permissions. But in this new context, it’s confusing.
  • Improved message for tab bars without tabs.
• I can always select icons for tabs and tab bars, but they apparently never show up. Maybe these are the icons that used to be displayed in the toolbar row. But as a user, I can’t add tabs there anyway, right?
  • Added a tooltip with an explanation.
• The attributes in the form editor are sorted case-sensitively. This isn’t intuitive.
  • Attributes in the form editor are now sorted case-insensitively.
• In tables and grids, there are different ways the displayed type is presented. In tables, it’s by qualified name, where you select from a flat list. And in grids, it’s by label with a tree-like representation of the types.
  • Uniform display for selecting the type of a table or grid.
• In tables, associations can be selected as the “list item type.” This is likely incorrect. If, however, it is correct, then “List Items” must also allow this, which is currently not the case.
• In grids, the “Default Columns” option is mandatory. In tables, it does not exist at all.
  • It is now mandatory in tables as well.
• When I configure a grid for DemoTypes:DemoTypes.All, I’m offered two columns. One of them is displayed as “Parent Element” while I’m configuring the view. But in the finished grid, it appears as [layout.element.grid.Grid.parent]. In both cases, the same names should be displayed.
  • The parent attribute was marked as HIDDEN using the tl:TLVisibility annotation. Attributes that are not visible are no longer available for column selection in grids and tables.
• ~~In grids, the “Parent Element” column is offered for DemoTypes:DemoTypes.All. This column does not exist in tables. ~~
  • When creating tables, you can now also configure which columns should be visible.
• When I create a grid for the type DemoTypes:DemoTypes.All, it displays a creation dialog.
  • This allows me to select the type to be created. It contains all local C types, all named "Demo C." Either these need to be removed, or they need labels so I can distinguish between them.
    • Local types receive the label of the tl:TLScope as a prefix.
  • I cannot set the parent element. This is problematic for StructuredElements because they are then not part of the tree. Not all views may handle this correctly. For example, if I create a Goto there, but the default view displays a tree next to the form, and the tree attempts to calculate a path to the root, this could lead to problems. Technically speaking, this is because the `parent` attribute is calculated from the `children` attribute. It would likely be better to use a different creation dialog for StructuredElements, in which the parent must be selected.
• If the layout is edited later, the names/titles of the views should be used there instead of “Layout Reference Component” for all elements.
  • tl:LayoutReference now has the additional property getTargetLabel, which matches the titleKey or the local name of the target component as a fallback. Instead of “Layout Reference Component,” the label of the root component of the reference’s target is now displayed.

Editing the Model

• When the user creates a new reference in the administration interface, they must select “Whether navigation in this reference is efficient.” Even as a developer, I don’t know what the system expects from me here.
  • This relates to the documentation for EndAspect#canNavigate. The documentation has been updated accordingly.

Entering TL Script Expressions

• When entering (single-line) TL script expressions, you can press CTRL+SPACE to get help. However, this is not mentioned anywhere. And no customer will figure that out on their own. Without this assistance, no customer will be able to enter anything correctly.
• Nowhere does it mention that a ":" must be entered as a separator after the module name, or that a "#" follows the type name, and there’s no support for this either.
• The same applies to the syntax for lambda expressions.
• The following error message doesn’t look right. Why does the == appear there twice?
  • 
  • The error message doesn’t help me at all. I had to ask Sven.
  • The error message comes directly from JavaCC—it always describes a token by its name and its characters, and in the case of ==, both are the same. It’s not possible (???) to improve the error message without improving JavaCC. The error message says that the token ` is expected instead of == . In this case, that’s because you forgot the `$ before the variable name model. It’s very difficult to generate this in an automatically generated error message from a grammar, since the compiler couldn’t possibly know what you intended to write.
• In single-line TL script fields, a tab is not interpreted as “change field,” but as “insert tab.” This is annoying when I’m configuring tables and can’t tab through the fields.
  • Shift-Tab does nothing, but it should tab backward.
  • The “Tab” and “Shift-Tab” key bindings are now disabled in the ACE Code Editor.
• In TL script fields, there is no input support for module singletons (DemoTypes#Root). (CTRL SPACE)
  • Module singletons are now supported via autocomplete.

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
• Create an in-app table of type DemoTypes:DemoTypes.All. "parent " must not be available as a selection for the ID and visible columns, since it is marked as "Hidden " via tl:TLVisibility.
• Check in any TLScript expression field (e.g., in the model-based search) to see if autocomplete suggestions are offered for module singletons. To do this, type, for example, "DemoTypes#" and check the suggestions, or explicitly press CTRL-SPACE to display the suggestions. "DemoTypes#ROOT " should appear as a suggestion.
• Check whether you can create a local form view. A table with a corresponding form can be easily created automatically using the script /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestFormCreation.script.xml (only up to and including the "Create Table" step). You can then create or reset a (local) form in the form’s burger menu. Both functions should update the form immediately after confirmation.