Re: readonly on trigger, etc.

John Boyer wrote:
> 
> I have an action item to respond to this email: 
> http://lists.w3.org/Archives/Public/www-forms/2007Feb/0055.html
> 
> 
> The minutes of the discussion about this email are just above here: 
>  http://lists.w3.org/Archives/Member/w3c-forms/2007JanMar/att-0219/20070321-3.html#ACTION3 
> 
> 
> The minutes incorrectly attribute to me the statement that I assume that 
> a readonly trigger cannot be activated because it's greyed out.  Erik 
> said it's greyed out and I disagreed.  The decision to disable a control 
> or to hide it are the typical outcomes of CSS styling for relevance, not 
> readonly.  I assumed a readonly trigger cannot be activated because 
> activation is the logical analog of providing input to a trigger.  

> It's unclear whether my assumption is correct or not.  Can you activate 
> a readonly trigger?

> And the bigger question is: does the readonly MIP even apply to trigger?

I think it is ok in theory to say that we do everything with CSS.

But in practice, I am in favor of supporting both relevant and readonly 
on triggers because that allows defining default styling rules, global 
for an XForms document, that make sense and that are very useful, namely:

* To hide and show the element depending on relevance

* To gray out the element depending on read-only

Note that this is only an example and you may choose to provide other 
defaults in your implementation. The point is that there are such two 
distinct use cases, and that it is convenient to be able to use two 
different MIPs to express them.

If we do support read-only on triggers, then I think it follows that a 
read-only trigger cannot be activated, in the same way that the user 
cannot cause events to be sent in a read-only input field, for example.

> Does the trigger receive valid/invalid events based on things like 
> constraints that might beattached to the node referenced by the single 
> node binding of the trigger?

We have two types of UI elements:

1. Those that hold a value, like xforms:input.

2. hose that don't, like xforms:trigger, xforms:submit and xforms:group 
(are there others?).

The former obviously get value change events and other MIP events as 
defined by the spec.

IMO, the latter should not get value change (xforms-value-changed) and 
validity events (xforms-valid / xforms-invalid) even if they are 
explicitly bound to instance data with @ref or @bind. They should not 
get xforms-value-changed because they don't hold a value. And they 
should not get validity events because since they don't have a value, 
that value cannot be valid or invalid.

However, they should receive xforms-enabled / xforms-disabled and 
xforms-readonly / xforms-readwrite events in the case they are 
explicitly bound with @ref or @bind, because these events are associated 
with MIPs that make sense for the control even in the absence of a value.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Sunday, 29 April 2007 03:41:33 UTC