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

Obviously you can count me as in favor of removing the "binding" 
property ;-)

-Erik

John Boyer wrote:
> 
> 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/
> 
> 


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

Received on Wednesday, 18 July 2007 23:11:35 UTC