Re: readonly on trigger, etc.

Hi Erik,

John wrote:
> > 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?

You replied:
> 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.

The problem with this approach is that you are only referring to
controls that you know about--the ones in the XForms UI. But what
about controls in other languages that might make use of the XForms
model? Or what about an XForms UI control that is extended to do
something else, using something like XBL?

In my view, all we should be defining in the context of the
relationship between the model and the UI, is that *any* element that
establishes a binding with an item in the model, will receive *all*
notifications about that data. And I'm not sure we really need to say
any more than that.

Now, quite what this element that is bound to the model data does with
the information it is being given is up to that element. If the design
is such that the user is able to modify the data, then that's fine,
and if the idea is to use state of the data to set the state of a
trigger, or even simply to set the evaluation context of some other
controls, then that's also fine. But what is done with the information
'within' the control shouldn't affect the information itself.

In my view, that's how we keep things encapsulated, ensure consistent
interfaces, and reduce the amount of toing and froing when defining
the behaviour of controls. (Because we need only define the notion of
binding generally.)

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Sunday, 29 April 2007 20:34:29 UTC