-
Type: Bug
-
Status: Resolved
-
Priority: Minor
-
Resolution: Fixed
-
Affects Version/s: 5.3 GA
-
Fix Version/s: 5.3.1
-
Component/s: None
-
Upgrade notes:
complex template currently uses "field_0" as a value for its subwidgets.
this is making the resolution of a second field (field_1) fail as it tries to take it resolve it from the previous "field_0" value instead of the parent widget "field_0" value (the variables are updated in the widget context).
Using "value" instead of "field_0" in the template solves the issue ("value" is also updated at each iteration over widgets) fixes the problem.
It makes it also possible to not provide any field information to the widget definition (for now we have to add an empty field declaration for the match to be performed).
sample error when running into this problem (where a complex defines a first field as a boolean and the second one as a string)
javax.el.PropertyNotFoundException: /widgets/my_widget_template_with_two_fields.xhtml @32,59 value="#
": /widgets/complex_widget_template.xhtml @34,58 value="#
{field_0.second_field_name}": Property 'second_field_name' not found on type java.lang.Boolean