W3C home > Mailing lists > Public > www-forms@w3.org > June 2006

Re: Switch inside a repeat in XForms 1.1 [was switch & repeat controls]

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Fri, 02 Jun 2006 18:05:00 +0200
Message-ID: <448061AC.3020109@orbeon.com>
To: www-forms@w3.org

Mikko Honkala wrote:

 > what do you mean by an instance node, which has "a repeat iteration
 > with switch associated with it ".

Apparently, I wasn't clear at all ;-) So I will elaborate:

Consider this:

<instance>
   <name>Mary</name>
   <name>Joe</name>
   <name>Sally</name>
</instance>

Then these controls (not necessarily very useful as is, but you get
the point):

<xforms:repeat nodeset="name" id="my-repeat">
   <xforms:switch>
     <xforms:case id="edit">
       <xforms:input ref="."/>
     </xforms:case>
     <xforms:case id="view">
       <xforms:output ref="."/>
     </xforms:case>
   </xforms:switch>
   <xforms:trigger>
     <xforms:label>Edit</xforms:label>
     <xforms:toggle ev:event="DOMActivate" case="edit"/>
   </xforms:trigger>
   <xforms:trigger>
     <xforms:label>Done</xforms:label>
     <xforms:toggle ev:event="DOMActivate" case="view"/>
   </xforms:trigger>
</xforms:repeat>

This will be displayed as three times two triggers, and initially
three input fields. Right?

Now we agree that as you interact with the triggers, you can get the
three virtual switches into different states. Example S1:

   edit
   view
   view

or example S2:

   view
   edit
   edit

etc.

They have a "life of their own". And each switch state is associated
with an iteration of the xforms:repeat. For the first iteration,
"edit", second one "view", etc.

Now I add this trigger within the repeat:

   <xforms:trigger>
     <xforms:label>Insert</xforms:label>
     <xforms:insert nodeset="../name" ev:event="DOMActivate"
                    at="index('my-repeat')" position="after"/>
   </xforms:trigger>

Let's assume the current index is 1. A node is inserted in the
instance, which now is:

<instance>
   <name>Mary</name>
   <name>Sally</name>
   <name>Joe</name>
   <name>Sally</name>
</instance>

The question to answer now is this: what are the states of the
switches? I think they should be, if S1 was the state before
insertion:

   edit
   view <-- repeat iteration associated with the newly inserted node
   view
   view

and if it was S2:

   view
   edit <-- repeat iteration associated with the newly inserted node
   edit
   edit

So to get there what I have done mentally is, for each virtual switch
"instance", associated its current state with the current node of the
enclosing repeat iteration. Then I have done my insertion into the
node-set, and finally I have make sure that the states of the switches
reflect the initial association with the node. This all done with the
purpose of getting a resulting state for each switch which is as close
as possible to what a user my expect.

Now if I use the @origin attribute in XForms 1.1 to perform my
insertion, and my source node is, say, in another instance, what
should the state of the new switch be? For S1:

   edit
   ???? <-- repeat iteration associated with the newly inserted node
   view
   view

and if it was S2:

   view
   ???? <-- repeat iteration associated with the newly inserted node
   edit
   edit

I suggested here that it be the default state for the switch, or:

   edit
   edit <-- repeat iteration associated with the newly inserted node
   view
   view

and if it was S2:

   view
   edit <-- repeat iteration associated with the newly inserted node
   edit
   edit

I hope this makes things clearer.

 > Note that:
 >
 > a) an instance node can be used in multiple repeats simultaneously

Sure.

 > b) the xforms 1.1 version of insert allows copying nodes from
 > anywhere in the instance data

Sure.

 > c) you can always use model-based switching if you want to keep the
 > state of the switches in the model. Use relevant MIP or <group
 > ref="@attr='testvalue'"/>, which will be hidden if
 > @attr!="testvalue".

The whole point of specifying the behavior of swiches in repeat is to
provide an alternative to model-based switching, otherwise we can
simply get rid of xforms:swich in general.

-Erik

 >
 > -mikko
 >
 > Erik Bruchez wrote:
 >>
 >> 1. What happens upon deletion, insertion or cloning of nodes in a
 >>    node-set addressed by an xforms:repeat with regard to the enclosed
 >>    switches?
 >>
 >>    I would expect the state of the switches to somehow stay associated
 >>    with the nodes the enclosing repeats are bound to, so that
 >>    visually, if a user deletes a row in a table, then the switches
 >>    update correctly.
 >>
 >>    Same thing upon insertion, and here I see two case:
 >>
 >>    o The insertion duplicates a node that does not have a repeat
 >>      iteration with switch associated with it (e.g. by using
 >>      xforms:insert/@origin. In this case, I expect the state of the
 >>      new switch to be the default state.
 >>
 >>    o The insertion duplicates one of the nodes that current has a
 >>      repeat iteration associated with it and an associated switch
 >>      (typical way xforms:insert works by cloning the last element of
 >>      the node-set). In this case, I would expect the state of the
 >>      switch to be the same as that of the switch associated with the
 >>      origin node.
 >>
 >>    Note that this is what we implement in OPS right now.

-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/
Received on Friday, 2 June 2006 16:05:11 GMT

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