Re: Suddenly confused about today's repeat index discussion

Hi Erik,

Yes, I think the problem is that insert (and the others) say that the 
index of *any nested repeat* within an updated [outer] repeat, the index 
of the nested repeat is reinitialized.

I prefer to use the word 'all', but that is what the author of this 
section meant and it's quite legal to say it that way.

So, agreed that when you insert a node that increases the repeat item set 
size of an outer repeat, if the newly created outer repeat item contains 
an inner repeat, then that inner repeat will have its repeat item set 
instantiated and will have its index "initialized". 

But that isn't reinitialized.  The index of the newly created inner repeat 
is initialized for the first time in its existence.

It doesn't make sense that the indexes of the other inner repeats in the 
other repeat items of the outer repeat would be affected at all by the 
creation of another outer repeat item.

It makes even less sense to change any inner repeat index when an outer 
repeat item is removed due to the delete action.

Generally, things that are true about a language construct at run-time 
should be invariant when that language construct is generated by a repeat. 
 A repeat is itself a language construct.  A repeat should not "lose" its 
index because of mutations made elsewhere in the document.  If repeat A is 
generated by repeat B, and repeat B mutates some other part of the 
document, repeat A should not forget where it was. 

Similar to insert/delete, the setindex action on an outer repeat B should 
not go out and reset any repeat A, whether or not a given repeat A was 
generated by repeat B.  Setindex should change the index of a given repeat 
and if other repeats must change, then setindex should be invoked on them 
too.

For example, with the current behavior, one actually cannot write a loop 
that sets the indexes of all inner repeats to some desired value because 
the only way to do that is to iterate the index of the outer repeat and, 
for each value, do a setindex on the inner repeat.  But right now, each 
time the outer repeat index is set, all of the inner repeat indexes are 
reinitialized!?!  It torments me so.

Finally, I did give some thought to the issue you raised about at least 
having a way for the form author to recover the old 1.0 behavior of 
reinitializing the inner repeats based on a focus change that sets the 
index of the outer repeat.  Well, this reinitialization is part of what 
I'm trying to get rid of because I don't think it serves the end-user to 
have a repeat forget where it was because the user decided to look at it. 
If it were a quantum particle, maybe, but not an XForms repeat.

I suppose, though, I won't get off that easily.  My immediate next 
reaction is that I'm pretty sure it is not so interesting that ALL the 
inner repeats got reset when the focus changes to a new repeat item of the 
outer repeat.  If that is the case, then I'm sure that a setindex encoded 
into a DOMFocusIn handler should do the trick, e.g.

<repeat nodeset="a/b">
   <group>
      <setindex ev:event="DOMFocusIn" repeat="R" index="5"/>

      <repeat id="R" nodeset="c/d">
         ...
      </repeat>
   </group>
</repeat>

However, if you do indeed want to reset *all* inner repeat indices any 
time a focus change causes the outer repeat index to be updated, then the 
above setindex action could be turned into an action sequence that 

1) saves the outer repeat index
2) iterates the outer repeat index so it can setindex on each inner repeat
3) restores the outer repeat index.

Finally, note that I am catching DOMFocusIn because that is the user event 
that is causing the outer index change, but if this is insufficient, then 
we could consider adding an xforms-scroll-changed event for repeats.  This 
would be a very nice addition to 1.1 anyway, but particularly nice if it 
allows us to get rid of the inner repeat index mangling.

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
08/08/2007 03:30 PM
Please respond to
ebruchez@orbeon.com


To
"Forms WG (new)" <public-forms@w3.org>
cc

Subject
Suddenly confused about today's repeat index discussion







All,

We discussed today that nested repeats should keep their own index 
information. Fine so far.

But it dawned on me that John's first example was that of an 
xforms:insert. In the case where new newly inserted node happens to be 
part of a repeat node-set, then the UI will update with a new set of 
controls. Fine too, but that would include the information about the 
nested repeat index, wouldn't it?

So while this discussion of nested repeat keeping individual index 
information makes sense when talking about xforms:setindex, I am not 
sure how much sense it makes in the case of xforms:insert: the new 
repeat iteration's nested repeat's index will have to be initialized to 
something, and that will be @startindex +/- index adjustment.

Or am I missing something?

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/