W3C home > Mailing lists > Public > www-forms@w3.org > September 2004

RE: binding controls inside repeats

From: John Boyer <JBoyer@PureEdge.com>
Date: Wed, 15 Sep 2004 10:01:11 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B52C71BAC@tigger.pureedge.com>
To: "Swithun Crowe" <swithun@swithun.com>, <www-forms@w3.org>

Hi Swithun,

The problem appears to be your use of the bind attribute.
I think X-Smiles is behaving correctly according to spec, but the bind
attribute isn't doing exactly what you want it to do.

The bind attribute you are using on the input and latter select1 are
references to bind elements, which are the sites of nodesets.
However, the input and select1 controls have a single node binding,
so the "first node rule" is applied.

Therefore, as you add "field" elements to your instance data, the
repeat control is updating by creating new rows, but the input and
latter select1 are still binding to the "date" and "sector" children
that appear *** in the first *** field element because of the first
node rule.

So, the controls on all your repeat rows inheriting relevance from
the date/sector elements of the first field because that's what they're
bound to.  In turn, this means that if you type data into an input on
any row of your repeat, the data should show up in the inputs of all
the repeat rows.

In order to accomplish your task, don't use the bind attribute.  Just
use ref="date" in the input and ref="sector" in the latter select1.
When ref is used, it is evaluated relative to the generating node for
whatever row of a repeat you happen to be in.  This will cause your
controls to connect to the proper field element's children, and
then the relevance will act as you want.

Best regards,
John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.


-----Original Message-----
From: Swithun Crowe [mailto:swithun@swithun.com]
Sent: Wednesday, September 15, 2004 12:56 AM
To: www-forms@w3.org
Subject: binding controls inside repeats



Hello
Does anyone know what exactly is supposed to happen when you have binds
like:

<xforms:bind id="date_bind" nodeset="field/date"
relevant="../@name='date'"/>
<xforms:bind id="sector_bind" nodeset="field/sector"
relevant="../@name='sector'"/>

and a repeat structure like:

<xforms:repeat nodeset="field">
  <xforms:select1 ref="@name">
    ... date ...
    ... sector ...
  </xforms:select1>

  <xforms:input bind="date_bind">
    ...
  </xforms:input>

  <xforms:select1 bind="sector_bind">
    ...
  </xforms:select1>
</xforms:repeat>

The first select1 should cause one of the controls below it to be made
visible, and for each iteration of the repeat, it should be possible to
choose a different value for @name, thus displaying a different control.

But what happens (with XSmiles 0.82) is that the first top select1 in the
first iteration of the repeat controls all the others. If I choose
'sector' in the first set of controls then I get the select1 control, but
when I add another set of controls to the repeat and choose 'date' I still
have a select1 menu (and not an input box).

It looks like the binds are applying the relevance criterion to each node
in the nodeset based on just the first node in the nodeset. Is XSmiles
behaving properly here, or can anyone suggest another way of doing this?

What I would like the interface to do is offer the appropriate control
based on the value of the first select1 in the repeat, and for the user to
add sets of controls to the repeat and choose different values with the
first select1.

Many thanks.

Swithun.
Received on Wednesday, 15 September 2004 17:01:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:58 GMT