W3C home > Mailing lists > Public > public-forms@w3.org > December 2011

Re: Variables in XForms

From: Leigh L Klotz Jr <leigh.klotz@xerox.com>
Date: Thu, 15 Dec 2011 09:22:52 -0800
Message-ID: <4EEA2CEC.8050306@xerox.com>
To: Erik Bruchez <ebruchez@orbeon.com>
CC: Public Forms <public-forms@w3.org>
On 12/13/2011 10:39 PM, Erik Bruchez wrote:
> ...
> There are a few points to clarify:
>
> 1. Whether variables can appear *within* core form controls (that is, 
> non-container controls).
>
> Such variables could be used by xforms:label, xforms:itemset, etc. You 
> could even go further and allow placement within xforms:choices, 
> xforms:item, etc.
>
> Orbeon does not support this at the moment. For me, it would be ok to 
> say that variables can be placed wherever a core form control can be 
> placed, even though there is nothing that would argue against placing 
> variables within core controls.
Is the case for putting variables inside form controls designed just for 
scoping control?  I suppose you could use a group if we don't support 
variables inside form controls, but that does mean you couldn't use the 
same variable twice inside two parts of a form control for different 
purposes.  Perhaps that's not such a limitation.

On the other hand, I wonder if variables could be useful inside itemset.

> 2. Whether a variable can omit the @value attribute and be initialized 
> with constant text content.
>
> Orbeon supports this. You can write:
>
> <xforms:var name="foo">bar</xforms:var>
>
> and the value takes the value of the string 'bar'. This is consistent 
> with XSLT and with other XForms constructs like xforms:label.
And xf:setvalue.  +1.
>
> You could go further and support nested xforms:output, although I 
> don't see the need for this.
Since we don't allow this in setvalue, we shouldn't do it here.  In case 
we decide to allow it there, consider this: it gets confusing if you 
have xf:output/@ref="x" where x has type 'xsd:date' and xf:output would 
render as a graphical item; what's the text representation?
>
> 3. Whether, like most controls, a variable supports a binding.
>
> Orbeon supports this. You can write:
>
> <xforms:var model="my-model" context="instance('bar')" ref="baz" 
> value="@gaga"/>
>
> The @value attribute evaluates relative to the binding, if any.
>
> The binding doesn't use bound MIPs (in particular relevance), but as 
> suggested the use of @model is convenient, and @context as well. This 
> makes attributes on the variable consistent with other controls. An 
> implementation can use the same code for variables and other controls 
> instead of special-casing variables.
The last sentence sounds great, and @model adn @context sound great too, 
but I'm totally confused about combining @ref and @value.  Does Orbeon 
have an extension to other form controls that enables this feature?  
What does it do?
>
> 4. Whether variables can be used from control bindings.
>
> For example:
>
> <xforms:var name="foo" value="bar"/>
> <xforms:input ref="$foo">...
>
> Orbeon supports this, as it's obviously useful. But it might be good 
> to explicitly say this in the spec.
I'd be willing for forgo this for now...
Received on Thursday, 15 December 2011 17:23:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:56 UTC