- From: John Boyer <boyerj@ca.ibm.com>
- Date: Thu, 1 Dec 2011 09:03:32 -0800
- To: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
- Cc: Forms WG <public-forms@w3.org>, Steven Pemberton <Steven.Pemberton@cwi.nl>
- Message-ID: <OF322E5AE5.42C6D2C6-ON88257959.005C984B-88257959.005DB642@ca.ibm.com>
Hi Steven (and Nick), Adding an attribute where one does not now exist is a structural change. At the current time, it is the case that all structural changes have easy to characterize/recognize (for the form author) properties, like corresponding to an insert or delete action and trackable by an xforms-insert or xforms-delete event on the instance. Would such events still occur by this new mechanism? If not, there are current form patterns that will break down, and we'll need the proponents of this feature to think about a replacement. That being said, there seems to be no compelling reason to add a new feature when we already have this feature. Write an xforms-model-construct-done handler and put an xforms:insert into it that conditionally runs in case the attribute is absent. The origin attribute can invoke the new attribute() function to create the attribute without needing it to preexist somewhere. By this mechanism, we still get an attribute and it is initialized properly, but it also hooks into the normal structural change mechanism so that it remains easy to both find and track structural changes in xforms documents. Cheers, John M. Boyer, Ph.D. Distinguished Engineer, IBM Forms and Smarter Web Applications IBM Canada Software Lab, Victoria E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com> To: Steven Pemberton <Steven.Pemberton@cwi.nl> Cc: Forms WG <public-forms@w3.org> Date: 01/12/2011 02:31 AM Subject: Re: @initial MIP If we allow predicates in the node expression it can become impossible to deterministically determine what the user wants. And for sure require some advanced XPath expression parsing. There are simple cases like: <require node="foo[position() <= 5]/@bar" initial="...expression..."/> (make sure there are 5 foo elements, and initialize the bar element when it isn't on those foo elements) (it will require some advanced XPath expression parsing to know what to do though) But what will the following expression do if there are no foo elements with a baz attribute equal to 1 or 2: <require node="foo[@baz= '1' or @baz = '2']/@bar" initial="...expression..."/> Should it create a new foo node with @baz attribute equal to 1, or should it be 2, or should we add the bad attribute to an existing foo node? The downside of not allowing predicates is that you won't be able to declaratively ensure that a repeated structure with a minimal number of iterations is available on form load. Kind regards, Nick Van den Bleeken R&D Manager Phone: +32 3 821 01 70 Office fax: +32 3 821 01 71 nick.van.den.bleeken@inventivegroup.com www.inventivedesigners.com On 01 Dec 2011, at 11:19, Steven Pemberton wrote: http://www.w3.org/MarkUp/Forms/wiki/DeclarativeInsert Nick and I noted that a form such as <bind ref="foo/@bar" initial=""/> intended to ensure that the foo element and its bar attribute both exist (in this case with no initial value) is a wrong use of @ref, since it works differently from how @ref works normally. It is possible that we have to introduce a separate element for this use case, such as (strawman): <require node="foo/@bar"/> and <require node="foo/@bar" initial="...expression..."/> Nick also had some remarks about restrictions on the selector in @node, which I hope he will add in a reply to this. Steven -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer
Attachments
Received on Thursday, 1 December 2011 17:04:13 UTC