The user has the possibility to define types in the application itself. He should also be able to create a new layout in the layout with which he can display or edit objects of such a 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 layput 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
- Migrate tab bar views to typed templates.
- This requires replacing the templates/tabbar.xml include tag with an arguments tag, which in turn must be converted to a
{{
#!xml
<config:template-call
xmlns:config="http://www.top-logic.com/ns/config/6.0" template="com.top_logic/legacyTabbar.template.xml"
>
</config>
}}
must be wrapped. 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. Migrating to the exact ticket version would use com.top_logic/tabbar.template.xml.
- Change masterFrame.layout.xml to mainTabbar.layout.xml.
- The masterFrame.layout.xml had used an untyped template materFrame.xml, where the property components was used e.g. by references to the tabs of the main tabbar.
{{
#!xml
<?xml version="1.0" encoding="utf-8" ?>
<include name="templates/masterFrame.xml">
<components>
<layout-reference resource="admin/index.layout.xml"/>
</components>
</include>
}}
Now there are three files.
* masterFrame.layout. xml uses the untyped template from templates/masterFrame.xml to create the MainLayout of the application and has a reference to masterContent.layout.xml.
* masterContent.layout.xml uses the untyped template from templates/masterContent.xml to add additional content e.g. a status bar and has a reference to mainTabbar.layout.xml for the main tabbar.
* mainTabbar.layout.xml contains all tabs for the main tabbar as references.
masterFrame.layout.xml and masterContent.layout.xml are inherited from TL and usually do not need to be changed or overwritten.
The references for the tabs of the main tabbar must be moved from masterFrame.layout.xml to mainTabbar.layout.xml. That means from 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.x ml is created with the 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 points
-
Store newly defined layouts in the database(layout_configurations) instead of under WEB-INF/layouts/0f5e4de8-138d-4170-8c85-ce4b99425de2.layout.xml -
Dynamically instantiable layout templates should have filenames called *.template.xml (instead of being compulsorily located in a (sub)folder called dynamic ). -
Show Publish and Export Layouts buttons only in design mode. - ~~Sichtems in top-level tab cannot be added.
~~
-
For configured components, it must be possible to edit (and possibly delete) the configuration after clicking "ok". -
Better enter number of subcomponents for new layout - or each layout needs parameters - maybe that's because you probably have to enter at least the default sizes! No booleans as text input, ...:
-
Complicated parameters need documentation, otherwise it is simply impossible to use the GUI, the order of parameters is important - first the tree root, then the children - otherwise you get a knot in your head e.g.:- Documentation from JavaDoc is used, needs to be added or improved on a case by case basis.
-
Tab configuration not possible at all tabs, but configuration button is shown anyway.
-
For main tabs you should also be able to configure an icon (for display in sidebar layout).- Icons can now be configured for all tabs.
-
Creating a grid table without Model Builder results in meaningless error message and error log messages: Can the error handling be improved? For a grid, after specifying the type - couldn't the expression all(`type`) be used as default model builder?- Expression is now mandatory. Default would be too costly / unclear how to implement.
-
In tabbars show single tabs only while tabbar is created. - Crash when editing an open dialog (edit view from top-level burger menu). Replacing the dialog does not work properly yet. Attached is a "patch" that replaces the dialog but does not update it. To do this, the dialog must be closed and reopened. Furthermore, the button in the toolbar of the DialogParent is also not adjusted when changed.
- Target specification for a command-by-expression does not work if the initially displayed default configuration is changed, e.g. to selection(self()).
-
Special command for "add dialog". - "Create" command that creates an object of a type to be selected (form of type definition and script that inserts the new object into its environment).
-
Duplicate commands for editing components partially duplicated. -
Scripting of GUI changes hangs when played in the script recorder. -
How to close a dialog from a configured command?
Test
- Scripts com.top_logic.demo/src/test/com/top_logic/demo/scripted/layout/**