The user has the option to define types within the application itself. The user should also be able to create a new layout in the layout editor that allows them to view or edit objects of that type.
Implementation
- Layout configurations are stored in the database: ` select * from layout_configurations;`
- Dynamically instantiable layout templates are parameterized via typed configuration (<config:template/>).
- Parameters are configured as property descriptors (properties/property)
#!xml
<config:template xmlns:config="http://www.top-logic.com/ns/config/6.0">
<properties> <!-- Config descriptor for the argument object -->
<property name="type"
mandatory="true"
type="String"
/>
</properties>
...
</config:template>
- Dynamic layout templates are included via <config:template-call> with an "arguments" config item
#!xml <config:template-call template="com.top_logic.element/dynamic/gridByType.xml"> <!-- Argument object matching the config descriptor from the template file. --> <arguments type="ohlfElement:OrgUnitFinance"/> </config:template-call>
Code Migration
- Convert tab bar views to typed templates.
- To do this, the `templates/tabbar.xml` ` include ` tag must be replaced with an `arguments ` tag, which in turn must be placed within a
{{{
#!xml
<config:template-call
xmlns:config="http://www.top-logic.com/ns/config/6.0" template="com.top_logic/legacyTabbar.template.xml"
>
</config>
}}}
. For example,
{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>
<include name="templates/tabbar.xml"
helpIDLegacy="main.admin.base.tabber"
z_legacy_componentName="adminBaseView"
z_legacy_tabBarName="adminBaseView_tabBar"
z_legacy_tabLabel="main.admin.base.tabber"
>
<components>
<layout-reference resource="com.top_logic/admin/model/list/adminLists.layout.xml"/>
</components>
</include>
}}}
to
{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>
<config:template-call
xmlns:config="http://www.top-logic.com/ns/config/6.0"
template="com.top_logic/legacyTabbar.template.xml"
>
<arguments
helpIDLegacy="main.admin.base.tabber"
z_legacy_componentName="adminBaseView"
z_legacy_tabBarName="adminBaseView_tabBar"
z_legacy_tabLabel="main.admin.base.tabber"
>
<components>
<layout-reference resource="com.top_logic/admin/model/list/adminLists.layout.xml"/>
</components>
</arguments>
</config:template-call>
}}}
Note: com.top_logic/legacyTabbar.template.xml is the direct migration to #25242. The migration to that specific ticket version would use com.top_logic/tabbar.template.xml.
- Switch from masterFrame.layout.xml to mainTabbar.layout.xml.
- The masterFrame.layout.xml had been using an untyped masterFrame.xml template, where the components property was typically populated, for example, by references to the tabs of the main tab bar.
{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>
<include name="templates/masterFrame.xml">
<components>
<layout-reference resource="admin/index.layout.xml"/>
</components>
</include>
}}}
There are now three files.
* masterFrame.layout.xml uses the untyped template from templates/masterFrame.xml to create the application’s main layout and references masterContent.layout.xml.
* masterContent.layout.xml uses the untyped template from templates/masterContent.xml to add additional content, such as a status bar, and references mainTabbar.layout.xml for the main tab bar.
* mainTabbar.layout.xml contains references to all tabs for the main tab bar.
masterFrame.layout.xml and masterContent.layout.xml are inherited from TL and generally do not need to be modified or overridden.
The references for the tabs in the main tab bar must be moved from masterFrame.layout.xml to mainTabbar.layout.xml. That is, from the file masterFrame.layout.xml
{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>
<include name="templates/masterFrame.xml">
<components>
<layout-reference resource="admin/index.layout.xml"/>
</components>
</include>
}}}
the file mainTabbar.layout.xml with the following content:
{{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>
<config:template-call
xmlns:config="http://www.top-logic.com/ns/config/6.0"
template="com.top_logic/maintabbar.template.xml"
>
<arguments>
<components>
<layout-reference resource="admin/index.layout.xml"/>
</components>
</arguments>
</config:template-call>
}}}
Open Issues
Save newly defined layouts in the database (layout_configurations) instead of under WEB-INF/layouts/0f5e4de8-138d-4170-8c85-ce4b99425de2.layout.xmlDynamically instantiable layout templates should have filenames ending in *.template.xml (instead of being required to reside in a (sub)folder named "dynamic" ).Display the "Publish" and "Export Layouts" buttons only in Design Mode.- ~~Views cannot be added to the top-level tab.
~~
For configured components, it must be possible to edit the configuration again after clicking "OK" (and possibly delete it again).It would be better to enter the number of subcomponents when creating a new layout—or each layout requires parameters—perhaps this is also because you apparently have to enter at least the default sizes! No Booleans as text input, ...:
Complex parameters require documentation; otherwise, it’s simply impossible to use the GUI. The order of parameters is important—first the tree root, then the children—otherwise it gets confusing, e.g.:- Documentation from JavaDoc is used but needs to be supplemented or improved on a case-by-case basis.
Tab configuration isn’t possible on all tabs, but the configuration button is still displayed.
It should also be possible to configure an icon for the main tab (for display in the sidebar layout).- Icons can now be configured for all tabs.
Creating a grid table without the Model Builder results in a vague error message and error log entries: Can the error handling be improved? For a grid, after specifying the type—couldn’t the expression `all(`Type`)` also be used as the default Model Builder?- The expression is now mandatory. A default option would be too complex / unclear how to implement.
In tab bars, display only individual tabs while the tab bar is being created.- Crash when editing an open dialog (Edit View from the top-level burger menu). Replacing the dialog does not yet work correctly. Attached is a “patch” that replaces the dialog but does not update it. To do so, the dialog must be closed and reopened. Furthermore, the button in the DialogParent’s toolbar is not updated when changes are made.
- Target specification for a "Command-by-expression" does not work if you change the initially displayed default configuration, e.g., to `selection(self())`.
Special command for “Add Dialog.”- "Create" command that creates an object of a selectable type (form consisting of a type definition and a script that inserts the new object into its environment).
Some commands for editing components are duplicated.Scripting of GUI changes freezes when played back in the script recorder.How do you close a dialog from a configured command?
Test
- Scripts com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/**