Re: Readonly, relevant attributes for trigger

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.