Re: XForms 1.1 Last Call: comment about 4.4.5 The xforms-insert Event (PR#108)

John & all,

 > Regarding the question of whether there was any kind of resolution,
 > no there was no resolution to remove the binding property.

That's what I feared ;-)

 > [...] but Leigh in particular was unhappy with the binding property
 > because it cannot be resolved to retrieve the nodeset without
 > knowing whether the binding value comes from a bind attribute or a
 > nodeset attribute.

There is more. Of course you can have:

   <xforms:insert context="A/B" nodeset="name" .../>
   <xforms:insert context="X/Y" nodeset="name" .../>

or even:

   <xforms:group ref="A/B">
     <xforms:insert nodeset="name" .../>
   </xforms:group>
   <xforms:group ref="X/Y">
     <xforms:insert nodeset="name" .../>
   </xforms:group>

 > We need a simple way for authors to be able to detect inserts and
 > deletes that are happening to particular repeated data sets when
 > there is more than one repeat in the form.  For example, if I have
 > two inserts or deletes that operate over A/B/name and X/Y/name, the
 > binding property of the events can easily be used to help me figure
 > out which kind of 'name' I am dealing with, so I can use conditional
 > logic to respond appropriately.

I don't disagree that it is a desirable requirement, although I don't
think I have hit the use case myself.

My feeling is that using the value of @bind or @nodeset is not
appropriate for this task, because neither one actually identifies
that node-set. Sure, the form author can tweak XPath expressions to
make the "binding" unique enough, but it is a clunky solution in my
opinion.

What about passing the id attribute of xforms:action instead? Would
that satisfy the requirement? Since ids are unique, you would have to
use different ids if you have a combination of multiple
xforms:insert/xforms:delete actions operating over that node-set, but
you could detect this, e.g.:

   if (starts-with(event('action-id'), 'repeat1-')) ...

There is also the possibility of adding a new attribute to
xforms:insert and xforms:delete just for that purpose. For example:

   <xforms:insert parameter="repeat1" .../>

This is a fairly common pattern in programming used typically with
callback functions: here we will get "called back" with xforms-insert,
and we want to be able to pass our own identifying information to that
callback by passing it to the action. We would recover it with
something like:

   event('parameter')

I would find either of these solutions better, because much more
consistent.

 > However, at the face to face, the alternative was proposed of using
 > a generate-id() function.  As I pointed out in my email below, this
 > proposal is more flawed because, although it is better for
 > insertion, it completely fails for deletion.

I agree this wouldn't be a good solution either.

-Erik

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

Received on Wednesday, 18 July 2007 11:10:51 UTC