The visibility rule of a control is evaluated against the coach's data at load and whenever the bound value changes; three reasons it "does not work" for a business object attribute, with the fix for each:
- The attribute is not initialised - tw.local.order.approved is undefined when order has no default; a rule approved == false is then false. Give the variable a default (Has default) or initialise it in a script before the coach.
- The rule references a different path than the control is bound to - visibility rules in the UI Toolkit are formulas that reference controls (${Approved}.getData()), not variables; the old (8.5.0) visibility "business data" rules compared a variable path. If the attribute is not bound to any control on the coach, put it into a hidden control (a Boolean bound to tw.local.order.approved) and reference that control.
- The change happens in code without the framework noticing - changing tw.local.order.approved = true in a client-side script on the same coach after load does not fire change events unless you go through the binding API or a control (${Approved}.setData(true)).
// UI Toolkit: Section "ApprovalDetails" > Visibility (formula, script mode)
${Approved}.getData() === true ? "EDITABLE" : "NONE" // values: EDITABLE, READONLY, NONE (hidden), or true/false on older toolkits
// setting the value so the rule re-evaluates
${Approved}.setData(true); // control API -> change event -> visibility updates
// or the binding API from a custom view: this.context.binding.set("value.approved", true)For the developerWorks scenario you linked (a view bound to a list element's attribute): inside a repeated view, reference relative controls (${../Approved}) and make sure the list element itself is initialised for every row. Debug by putting the same expression into an Output Text's formula - you see what the rule sees.
References