Re: implementors question: correct behavior of nested nodeset in repeat

John & all,

 > Although there is reasonably strong support for removing the notion
 > of homogeneous collection in principle, I believe we did not resolve
 > to do so.

As an official WG resolution, no, I don't think so.

 > I believe the sticking point was around the loss of the single
 > common parent more than anything else, although continuity is useful
 > too.

In our implementation, we have not found any usefulness in having a
common parent or continuity as an assumption.

If a form author wants a common parent and continuity, he is of course
free to use that, and that is in fact a very common use-case.

 > But for the repeat itself, it becomes more difficult to
 > *efficiently* detect whether the repeat needs to be updated.  One
 > could, for example, create a listener on the single common parent to
 > detect any addition or deletion of a child element and use that to
 > know whether the nodeset for the repeat needs to be re-evaluated.
 > The nodeset may still be the same, in which case the repeat does not
 > get updated, but having the single common parent as the focal point
 > means that in a larger form I don't have to check every repeat
 > nodeset whenever *any* node is inserted or deleted.

 > If we make this change, then the addition or deletion of a node *in
 > any instance* would require the reevaluation of all nodesets of all
 > repeats bound to that model.  It can be done, but it's slower.

You could probably still make your implementation more efficient when
you detect a homogeneous node-set. Then it is up to the form author to
decide if he wants faster performance and restrict himself to a
homogeneous collection, or potentially slower performance and enjoy
unrestricted repeats. The performance argument is fairly theoretical
anyway...

I think that it is completely reasonable and desirable to remove this
restriction for the following reasons:

* It makes the spec confusing because the reason for the existence of
   the restriction is not explained and probably difficult to
   convincingly explain. Even XForms specialists in this mailing-list
   have trouble explaining to each other why it is a good restriction
   to have!

* Removing the restriction arguably can make an implementation
   simpler. At worst, it won't make the implementation much more
   complex. Probably that several XForms implementors are likely to be
   able to confirm this.

* xforms:repeat is one of the most powerful features of XForms, and
   there are numerous use cases where this restriction gets in the
   way. Remember also that you don't always use xforms:insert and
   xforms:delete with xforms:repeat: you may have "read-only"
   xforms:repeat (repetitions over collections that don't change over
   the life or the form), or use a repeat on an instance that is
   updated by replacement (a point not really covered by the spec I
   believe).

-Erik

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

Received on Thursday, 1 March 2007 00:27:09 UTC