- From: John Boyer <boyerj@ca.ibm.com>
- Date: Sat, 28 Apr 2007 17:19:14 -0700
- To: Guntis Ozols <guntiso@latnet.lv>
- Cc: www-forms@w3.org, www-forms-request@w3.org
- Message-ID: <OF4D5A3598.9C56AAE2-ON882572CC.0000EB88-882572CC.0001C38B@ca.ibm.com>
Hi Guntis, Answers inline. 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 Guntis Ozols <guntiso@latnet.lv> Sent by: www-forms-request@w3.org 02/12/2007 03:09 PM To www-forms@w3.org cc Subject Readonly, relevant attributes for trigger Could you add 'relevant' and 'readonly' attributes to the trigger element (instead of bind)? Spec is very confusing about trigger binding. Here's what the spec says: > Data Binding Restrictions: Binds to any node. Well, OK, why? JB: Hmm. Why not? Trigger can bind to any node to pick up MIPs from that node. Why would we say certain types of nodes cannot be bound? > This form control does not directly interact with form data, That's what I'm saying. What's the reason behind this? JB: Because the form author chose to use a trigger control, which does not modify the value/content of the node to which it is bound. The trigger is like a button. A button is something you press and as a result of the pressing you get a DOMActivate. An event handler for DOMActivate *could* modify data using XForms actions, but a button doesn't directly take any user input. If the form author wants to collect user input to store in a data node, then the form author should use an input control. > but is affected by model item properties of the bound node, Which ones? JB: All of them. > thus binding attributes are not required. That's the point. In real life, for me it means that I have to create helper instance + helper bindings (bloating, again), just to manage relevant/readonly for buttons, because there is NO node in instance data with proper values for these attributes. If that's the intention, could this be clarified in the spec. Otherwise, attribute solution is preferred. JB: Because there are no binding restrictions, the form author could pick any node in the data and attach the right formulae to it using an xforms bind with a nodeset of the selected node and other attributes like relevant or readonly. Yes, this was the intent for XForms 1.0 and remained so for XForms 1.1. However, it is recorded as a future feature request related to XForms transitional to be able to attach more attributes to controls directly. Thank you, and forgive my ignorance. Guntis P.S. This concludes my personal issue list with XForms spec, was 5 for spec 1.0, left 3. I was very happy to find out that other issues are already addressed in 1.1 Working Draft. I am authoring/generating XForms for over a year now.
Received on Sunday, 29 April 2007 00:19:27 UTC