- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 19 Jun 2007 13:29:53 -0700
- To: ebruchez@orbeon.com
- Cc: public-forms@w3.org, public-forms-request@w3.org, www-forms-editor@w3.org
- Message-ID: <OF9729126E.B7F1DB40-ON882572FF.006F9342-882572FF.00709945@ca.ibm.com>
The use case was described at the face-to-face, though it does not have to be solved by the particular property specified. The issue is that xforms-insert and xforms-delete are kind of useless if you have no real way of detecting the exact nodes being inserted or deleted (deleted being the harder case because you lose the ancestors). The binding property was a simple "thunk" that could often be used to synchronize the operation of insert and delete on a particulare nodeset as being distinct from all other nodesets so that you can write conditional event handlers for xforms-insert and xforms-delete that only take certain actions if a particular nodeset has been mutated. One argument against is that the binding property doesn't tell you whether the binding was made by an XPath or an IDREF to a bind. I'm sure other arguments against will be posted in response to this email, but I wouldn't be happy to see this feature go away unless replaced with something better. While less than technically perfect in a declarative world, I do not think it is broken really. It's just that it does what it does, so it only works if you use it with care. I'd like something better, but we are wanting in that department. For example, the suggested alternative was to add a generate-id() function, so the 'if' on the event handler could compare nodes inserted/deleted with those obtained by specific XPaths. I believe this works for the insert case and fails for the delete case. Either way, it would help if you could stay on, Erik, as author of things related to insert/delete and their events. Would you be able to do this? Cheers, 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 06/18/2007 09:18 AM Please respond to ebruchez@orbeon.com To public-forms@w3.org cc www-forms-editor@w3.org Subject Re: XForms 1.1 Last Call: comment about 4.4.5 The xforms-insert Event (PR#108) All, Just to make things clear: the request for use case clarification falls on John, or on whoever thinks that the "binding" property as currently specified should stay in the spec. If no compelling use case is proposed, we need to drop the current "binding" property (but other properties can be proposed if they satisfy a use case deemed worthy by the WG). Best, -Erik Ulrich Nicolas LissXX wrote: > Erik, > > we accept your request to clarify that the empty is string is returned by insert > event binding if none is specified. We also ask for clarification on the > feature and its use case, because in general, it is not possible for the form > author to resolve the value without knowing the context and without knowing > whether the binding is a bind IDREF or an XPath expression. > > Regards, > Ulrich Nicolas Lissé. > For the Forms WG > >> All, >> >> This is a comment about the "binding" property or these sections. >> Section 4.4.5 says: >> >> "The attribute value of the insert action's nodeset or bind attribute." >> >> However, both @bind and @nodeset are optional with xforms:insert. We >> should say what the "binding" property returns when this occurs. >> >> By the way, I believe I raised this in the past already, but I am not >> sure why this property is useful anyway. I would suggest simply getting >> rid of it unless a compelling use case for it is proposed. >> >> -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 Tuesday, 19 June 2007 20:30:25 UTC