Ability to use variables for min, max, etc.

[avernet]

This is a feature that the data-bound select1 calls for. It would allow form authors to easily create linked data-bound select1 control in Form Builder, e.g. (LHHA and table cells removed for clarity):

<fr:databound-select1 bind="state-bind"
    resource="/xforms-sandbox/service/zip-states"/>
<fr:databound-select1 bind="city-bind"
    resource="/xforms-sandbox/service/zip-cities?state-abbreviation={$state}"/>
<fr:databound-select1 ref="zip" 
    resource="/xforms-sandbox/service/zip-zips?state-abbreviation={$state}&amp;city={$city}">

Without bind names exposed as variables, form authors need to know what the structure of the XML is to refer to the value of another field.

[ebruchez]

When done, also update this doc.

[ebruchez]

This should be much easier with the new and improved model variable resolver.

[ebruchez]

This also makes sense for repeated fr:grid and fr:section so their min and max AVTs can refer to other controls. See #1665.

[avernet]

+1 from community

[ebruchez]

+1 from me as I was writing an example

[ebruchez]

See #2910 for a function to access the value of a control.

[ebruchez]

In an example, I tried to use bind('state-bind'), and it doesn't work, because databound-select1.xbl evaluates its itemset in the inner scope. Using xxf:instance('fr-form-instance')//state works, but it's cumbersome.

Here again, a Form Runner function would help.

[avernet]

+1 from customer who hit the use case mentioned earlier by Erik, and expected to be able to refer to the value of a control when setting the min/max number of iterations in a grid.

[ebruchez]

+1 from me for min and max in repeated grid. Referrring to $min/$max doesn't work.

[ebruchez]

+1 from user

[ebruchez]

+1 from customer

[ebruchez]

See also:

• Function to access the value of a control #2910 (comment)
• Dynamic LHH: simpler way to get typed formatted control value #3772

With #2910 implemented, what would it take to make this work? We would like that:

• the user writes variables in min, max, and other places
• this gets translated to a function call and back to a variable when editing

Q: How can we do this translation? Parsing and rewriting XPath expressions is not hard, but round-tripping to a string expression is not reliably possible with Saxon. One possibility is to do the rewrite at XBL processing time, at least for fr:grid and fr:section for min and max. This is how it's done now:

<xf:var name="min">
    <xsl:copy-of select="namespace::*"/>
    <xxf:value value="$repeat-context-outer/xxf:evaluate-avt($min-avt)" xxbl:scope="outer"/>
</xf:var>

But we should probably use fr:component-param-value() instead. Entered and fixed #3795.

So which code should do the rewrite of the expression? Should fr:component-param-value(), which translates to xxf:component-param-value(), do it? But then what if somebody wants to use a local variable as the parameter name?

UPDATE: By "local variable" I guess I meant something like for $foo in . return ....

Should other Form Runner code do the translation when assembling the form?

• decide where the translation takes place
• implement
• doc

[ebruchez]

Another way to look at min and max, in particular, is like max-length and the character counter: it could be expressed as a constraint on the grid. The function would check the constraint and annotate the data. fr:grid and fr:section would read the annotated data like fr:character-counter. Doing this, variables would work naturally without any translation, since the constraint is within binds.

One issue with this is to handle backward-compatibility. annotate.xpl could migrate existing forms to use constraints. Form Builder-created forms are unlikely to use expressions which would not run identically in the context of fr:grid and in the context of the binds.

Form Builder would have to read the min and max from the constraint in this case, not from the control.

[ebruchez]

For fr:databound-select1, this is another story. I don't think we'd like to set the resource name in a bind constraint, would we?

[ebruchez]

After discussion with @avernet, handling min and max as constraints appears like a good solution.

[ebruchez]

Similar requirement for dynamic LHH(A) formulas to be able to refer to variables. See #3807.

[avernet]

+1 from customer to make variables visible in the view, so we can use them in templates

[avernet]

+1 from user who would like to be able to refer to the value of another field with $other-field from the resource URL of a Dynamic dropdown.

[avernet]

+1 from customer

[ebruchez]

In the model, $foo returns an XML node. However with the current implementation, in the view, we use fr:control-string-value() which returns a string.

• double-check that $foo returns the node
• should/could this also be the case in the view, for consistency, in which case we shouldn't use fr:control-string-value()
• also consider whether $foo should/could return possibly a sequence
• doc behavior in both cases!

[ebruchez]

So now, in the view, $foo also returns a sequence of items, not a string value.

Added a clarification section in the doc about the variable notation and what it does.

[ebruchez]

In email templates, "The Form Runner function library is not in scope in this XSLT", and right now we use saxon:evaluate(). If we create an expression which contains frf:controlVariableValue(), we should be able to evaluate it as there is, in fact, an XFormsContainingDocument in scope.

[ebruchez]

Updated the documentation about renaming.

[ebruchez]

Added documentation about where formulas can be used.