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

Good point indeed about the use of context in insert and delete.

I don't like features that encourage authors not to use a best practice on 
another feature (e.g. using context on insert/delete). 

Although I prefer to have a more useful xforms-insert and xforms-delete, I 
could live with the removal of the binding property.  It now seems clear 
that it does not provide much benefit over calling local-name() or some 
such function on the inserted or deleted node(s). 

I also suspect Leigh feels more strongly that the feature should be 
removed than I or anyone else feels about retaining it.

If any working group member has an objection to removing the binding 
property from the xforms-insert and xforms-delete events, please say so on 
this list before the next telecon.

Thanks,
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
07/18/2007 04:10 AM
Please respond to
ebruchez@orbeon.com


To
public-forms@w3.org
cc

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