Bugfix
(User-visible)
Edit views
-
I would like to have the "Reset" button for the tab selection dialog. For example, when I remove a view in the demo, quite a few new ones are added in the options. As a result, I no longer know which of them to select so that it is the same as before.-
The "Reset Layout Configuration" button in the Burger menu is grayed out, if that's what it's supposed to do. - Problem fixed, the reset button is now active when there is a configuration and not vice versa.
-
-
There is an extra button for inserting a new tab. But this button first opens a dialog, in which exactly one selection field with exactly one option "Tab" is displayed. This option is also not preselected, but must be selected first. Can't the whole dialog be omitted, if the button is already there to create a tab?-
The dialog creation is as strange as the tab creation. - Fixed, as long as there is only one option (depending on the available templates) no selection dialog is shown.
-
- The dialog to configure a new tab is way too big for its three input fields.
- Yes, but that would be too much work to customize - the template would also have to be able to determine the dialog size.
- ~~When a new tab is created, it would be nice if it is selected directly. Because you probably want to fill it with content in the next step. ~~
- Newly created tabs are selected.
-
A newly created subject object should be selected directly. -
When configuring for example a table view, all types in the system are offered in a big drop-down field. I would like to have something more practical. Something like when creating new types for selecting the top types. Just that "Search as you type" with qualified names works. And that the internal types are filtered away. Model based search already has functionality for filtering and a ready heuristic.- When selecting the list item type, a selection dialog is now opened, where the fully qualified name of a type can now be entered 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" and saying "Are you sure you want to perform this action?" This is unsettling to me. Why would I //not// want to do this? It should be explained here what the consequences are, what's against it and what's for it.- Improved message when exporting layouts.
- On some tabs the button "Delete view" is grayed out. Reason: "Component is not instantiated from a typed template." But if I click "Configure tab" instead, I can remove the view. This is inconsistent. This can be reproduced in the demo with the Search tab, for example.
- "Configure tab" and "Delete view" do not perform the same operation. "Configure Tabs", as the name suggests, configures the tabs or tabs. That is, in the tabbar configuration tl:LayoutReference are ordered, added or removed. The layout of the tabs, however, is not changed further. "Delete View", on the other hand, removes the complete layout of this view, including the partial views. Specifically, the layout is removed from the database. However, the command should only be executable if there are no references or component channels linked to (slave) components outside the view to be deleted. This difference should be made clear to the user.
- In some views the button "Delete view" is active. But when it is pressed, an error message comes up: "Component could not be removed, because other, not to be deleted, components have references to this component." But if I click "Configure tab" instead, I can remove the view. This can be reproduced in the demo with the "Tables" tab, for example. This is inconsistent in two ways:
- Either the view can be removed or it cannot be removed. If it cannot be removed, it should be marked accordingly in the selection list. We can mark options as "cannot be removed" after all.
- 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 clicking Ok in the tab creation dialog. The button to delete the tabs there is also grayed out accordingly. This can be reproduced in the demo, for example, if a tab is to be inserted next to "Structures -> Type demo -> Type demo". At least the button should be grayed out, just like the button for deleting tabs. ~~
- Is already solved by a change in ticket #25095 by making the "Add Tab" command only executable if the tabbar is instantiated from a typed template.
-
New tables are not initially sorted, although they initially have a name column. Tested with a table for DemoTypes:DemoTypes.All.- It is sorted by the ID column initially.
- If I reconfigure a component afterwards, I am also given my own component as the source for the model. This is never useful, I think. If this cannot be prevented, we must at least test whether this leads to endless loops.
-
If I don't enter a name for views, and want to refer to it in another view with the model, it is displayed using its qualified generated name: 7616d4b7-ea88-4ba5-9a39-cc1aa1b763af.layout.xml#Table. As long as that is unique, the last part "Table" would be much better. And if that's not unique, the generated name won't help either. A stable counter ("Table 2") would be much more user-friendly and works just as well when selected by "trial and error".- Names for views are now mandatory.
- When selecting the model, there are "-----", "No model" and "Component -> -----" among others. Since it makes practically no difference, this only confuses unnecessarily.
- Ideally, "----" does not exist as an option in the burger menu of a tl:ModelSpec property and "No model", i.e. tl:ModelSpec$Null, is initially selected. This is not easy to implement in this form. Either you mark the property as tl:Mandatory, but then no option can be selected initially (in this case Provider by Expression is selected initially) or you mark the property with tl:NonNullable and set a tl:ItemDefault. However, this will conflict with the tl:ModelSpec$Format. tl:ModelSpec$Null will be serialized to null(), which in turn will be deserialized to the default value, which is null. Since the property is tl:NonNullable, this results in an error.
-
After creating a new form view, I would like to define the form for that view. There is no button to do this. And nobody guesses that this is hidden in the tab "Administration -> Basic Administration -> Attributes -> Properties": now here I switch to edit mode, select the right customization, know that the icon is a button, and there I am. I understand the logic behind it, that a form is defined for a type. And that is the view to edit types. And the form definition is stored as an annotation on the type. But that is far from intuitive for a user who is building his view.- The view of the forms can now be edited locally. For this purpose, there is now another property of type tl:FormDefinition in the typed template for forms. For each tl:FormComponent instantiated by a typed template, a command exists to edit the underlying tl:FormDefinition.
- That the tab to edit "Classes" is called "Attributes" is also not intuitive. Historically grown, but unfortunately wrong nowadays. (If this is changed, tests need to be adjusted).
- The parameters that TL script expressions have as values all need documentation and preferably examples for the most common case. What do I (or the customer) know what to put in "surface model" when configuring a tree. Since we all have defined quite a few tables and trees, it may be all clear and obvious to us. But not for a customer.
- And also for the other parameters the documentation should be proofread. For example, the tooltip for the "Node expansion" checkbox reads "Whether it is possible to expand a specific tree node." What "specific tree node"? Do I need to define that somewhere? Where? And why would I want to turn that off? That's what the function that calculates the child nodes is for. This has to be adjusted if certain nodes should not have children, right? Or does this checkbox generally turn off that nodes can be expanded? But it says "a specific tree node". And that doesn't make sense in a tree either. Then I see only one level. Or is everything always expanded then? That confuses me totally. Although I have already built a few trees in Top-Logic.
-
When I configure a new, empty tab bar, "Access was denied" is displayed as content. More appropriate would be "No content", for example. Presumably the text was previously accurate, as this condition only occurred when all tabs were hidden due to permission. But in this new context, it's confusing.- Message improved for tabbar without tabs.
-
I can always select icons for tabs and tab bars, but they never seem to be displayed. Possibly these are the icons that are displayed in the toolbar line so far. But as a user I can't add tabs there anyway, can I?- Tooltip with explanation added.
-
The attributes in the form editor are sorted case sensitive. This is not intuitive.- Attributes in the form editor are now sorted case insensitive.
-
In tables and in grids there are different ways how the displayed type is shown. In tables by qualified name, selecting from a flat list. And in grids by label with a tree-like representation of the types.- Uniform representation for selecting the type of a table or grid.
-
In tables, associations can be selected as "list item type". This is probably wrong. If, on the other hand, it is correct, "List elements" must also allow this, which is currently not the case. -
In grids the option "Default columns" is mandatory. In tables it does not exist at all.- Also in tables now mandatory.
-
When I configure a grid for DemoTypes:DemoTypes.All, I am offered two columns. One of them is shown as "parent element" as long as I configure the view. But in the finished grid then as [layout.element.grid.Grid.parent]. In both cases, the same names should be displayed.- The parent attribute has been marked as HIDDEN using the tl:TLVisibility annotation. Attributes that are not visible are now not available for selecting columns in grids and tables.
- ~~In grids, for DemoTypes:DemoTypes.All, I am offered the "parent element" column. In tables this column does not exist. ~~
- When creating tables, it is now also possible to configure columns that should be visible.
- When I create a grid for the type DemoTypes:DemoTypes.All, it brings a creation dialog.
-
It lets me select the type to create. There are all local C-types included, all with the name "Demo C". Either they have to go, or they need labels with which I can distinguish them.- Local types get the label of the tl:TLScope as prefix.
- I can't set the parent element. This is unfavorable for StructuredElements, because then they are not part of the tree. Not all views may be able to handle this. For example, if I make a goto there, but the default view shows a tree next to the form, and the tree tries to calculate a path to root, that could cause problems. Technically, this is because the parent attribute is calculated from the children attribute. Probably it would be better to use a different layout dialog for StructuredElements, where the parent has to be selected.
-
-
If the layout is edited afterwards, 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 fallback. Instead of "layout reference component", the label of the root component of the target of the reference is now displayed.
Edit model
-
When the user creates a new reference in the administration, he has to select "Whether the navigation in this reference is efficient". There, even as a developer, I don't know what the system wants from me.- This is the documentation of EndAspect#canNavigate. The documentation has been supplemented accordingly.
Input of TL script expressions
- When entering (single-line) TL script expressions, you can press CTRL SPACE to get support. But it is not pointed out. And no customer will guess that. And without this support no customer will be able to enter anything correct.
- That after the name of the module a ":" must be entered as separator, and after the type name a "#" is nowhere and there is also no support for it.
- The same with the syntax for lambda expressions.
-
The following error message does not look right. Why does the == appear twice there?-
The error message does not help me. I had to ask Sven. - The error message comes directly from JavaCC - he always describes a token by its name and its characters, for == both are the same. It is not possible (??) to improve the error message without improving JavaCC. The error message says that instead of == the token (` is expected. At this point it is because you forgot the `$ in front of the variable name model. This is very difficult to create in an automatically generated error message from a grammar, because the compiler could not know what you wanted 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 should tab backwards. - The "Tab" and "Shift-Tab" key binding is now disabled in the ACE CodeEditor.
-
-
In TL script fields there is no support for singletons of modules(DemoTypes#Root) when typing. (CTRL SPACE)- Singletons of modules are now supported using 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, because it is marked as Hidden by tl:TLVisibility.
- Check in any TLScript expression field (e.g. in the model-based search) whether an autocomplete is offered for module singletons. For example, type DemoTypes# and check the suggestions, or explicitly press CTRL-SPACE to display the suggestions. DemoTypes#ROOT should be displayed as a suggestion.
- Check if you can create a local form view. A table with a corresponding form can easily be created automatically using the script /com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/TestFormCreation.script.xml (only up to the point "Create table" inclusive). Afterwards a (local) form can be created or reset in the burger menu of the form. Both functionalities should update the form directly after confirmation.