Re: Suddenly confused about today's repeat index discussion

John & all,

 > 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.

Good point.

 > 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.

I tend to agree.

We will have to make it clear in the spec that:

* Each nested repeat keeps its own index. Maybe we could get there by
   just adding a note?

* No more reinitialization takes place, which is different from 1.0.

I don't have the spec in front of me now, but we should also make sure
we say that the indexes are adjusted during refresh, so that after a
refresh you don't have indexes that are out of bounds.

Finally, I mentioned during the call that there are several instances
where indexes can change:

1. xforms:insert
2. xforms:delete
3. xforms:setindex
4. User-triggered UI action (such as clicking on a row in a table)
5. Instance replacement

It would be nice to have this summary somewhere, if we agree that it
is correct.

I don't think that #5 is tackled at all. I guess that just replacing
the instance won't change indexes, especially since we have now
decided that repeat indexes live their own life, however the
subsequent refresh will have to make sure that indexes are not out of
bounds. If refresh specifies that then we should be good to go.

 > 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.

Well, there are many things that authors may want to do in a user
interface. So far, I don't think that XForms has tried to enforce good
or bad UI practices, although it has built on existing concepts such
as focus and maybe introduced new ones such as repeat indexes. I don't
think we should necessarily start now deciding too much for authors
what is best, especially since this is very subjective and may depend
on the particular application.

But the above is partly rhethorical. I think that the new behavior is
better than the old one, however it would be a shame to remove a
feature (even if some consider it a bug).

 > 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.

I agree, I am not interested in doing that.

 > 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>

Right, that should work.

 > Finally, note that I am catching DOMFocusIn because that is the user
 > event

I don't think our implementation dispatches DomFocusIn on groups:
i.e., if you focus on a control within a group, you will get
DOMFocusIn, and that will bubble, but if you click on the area of the
group outside any other control, then we don't dispatch the
event. What do other implementations do?

 > 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.

Not sure it whould be called "scroll", since scrolling usually means
shifting an area of the UI up or down, and this may not happen when
just changing an index. But such an event would be quite usueful.

-Erik

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

Received on Monday, 13 August 2007 11:32:07 UTC