major
minor
major
minor
#26382
Error messages "Duplicate tag name..." when starting an application in the IDE from a TL-Studio
#26405
TTypeRewriter logs warning "Unable to resolve items by external reference" also unnecessarily
#26431
Changed superclass relationship leads to changed attribute list in the form editor only after a restart
#26484
In-app template for grid and tables: Function "Verifier for use as list item" does not get component model
#26536
When rendering HTML from TLScript expressions, configured renderers are not taken into account
#26797
Transaction with user input: invisible properties of the form model cannot be assigned values (initialized)
#26885
Constraints on declarative forms with arguments from a container reference lead to errors for new elements
#26921
ClassCastException when evaluating security rules that refer to (non-structuredElement) singletons of a module.
#26922
With generated subject classes, a default provider of an attribute in a non-structure class does not get a create context
#26988
In-app documentation generator does not extract documentation for overwritten config properties
#27027
Declarative forms: SelectField disappears after upload if option list depends on mandatory property
#27042
MaintenanceJspBase should write to the log first, then to the client, instead of the other way around.
enhancement
major
#26444
Specification of the context object in TL-Script Object creation
Currently, there is no way to pass the asset context to a default value function when the object is created in a TL Script operation.
With the "Default Value" customization, attributes of new instances can be assigned a default value. The function for calculating a dynamic sequence name receives "the creation context" of the new instance to be created.
This also appears to work for the form-based creation of containment instances in composition relationships.
However, if the new instances are not created using a form, this creation context is not automatically defined:
For example, the command handler using an expression on a table operates on the selected row as the context, creates a composite instance, and links it to the context. In this case, the function for calculating the dynamic sequence for the default value receives the "null" creation context.
In contrast, an “Object Creation Dialog” also receives the selected row as its model, creates the new composite instance, and links it to the selected context in its link operation. In this case, this creation context is also passed to the function for calculating the dynamic sequence for the default value. However, if such an object creation process generates the context object *and* the first composite instance *simultaneously*, the component model of the creation dialog is irrelevant. In this case, the newly created context object would be the correct creation context, not the selected row.
If it were possible to pass the object just created as a parameter to the function that calculates the dynamic sequence name, and if one could navigate from this instance to its container (composite parent), this problem would be resolved. Such default values could then be calculated only *after* the link operation...
That also seems to be the better way to phrase it: If the creation context of a composite instance is not derived from the component model but rather from the link operation during creation, default values with dynamic sequence names do not work.
Solution
The TL-Script function ` new() ` now accepts an additional optional argument in which the creation context can be specified. This creation context is also made available to any default value providers. If the creation is performed in a script, the creation context can be explicitly specified in this way.
new(`my.module:MyType`, $myContext)
Test
- test.com.top_logic.model.search.expr.TestSearchExpression.testCreateWithContext()