- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 19 Jul 2007 01:11:29 +0200
- To: public-forms@w3.org
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