Re: Disabling a button based on validity

Hi Erik,

The reason you get the xforms-valid and xforms-invalid whenever a bound
instance node changes is because an author might use that event to
provide a message saying this field is invalid. If the processor only
sends the event on a change in validity you would get such a dialog for
the first change to invalid, but if the user changes the value again he
would not get the message but the node would still be invalid.

The usecase discussed in this mail thread seems to be a very common
scenario and should be dealt with by the specification. I don't think it
should be done by changing the way events are dispatched at the moment
as it is to tedius to implement the functionality with counters. Also
that method might not reflect the true validity of the instance as it
only reflects the validaty of any bound node in the UI.

I believe that the validity function in XPath could be used to solve
this usecase (which is properly why formsPlayer has implemented it and
exforms.org has an extension function for it), however depending on the
formulation of the function it might also be tedious. E.g. in our
current usecase you would like to have the validity with regards to a
relevant subtree not for single nodes.

Best regards,
David

>>> Erik Bruchez <erik@bruchez.org> 27-10-05 17:37 >>>

Erik Bruchez wrote:

>> This extra-code is not so easy to do for me. And furthermore
difficult 
>> since David Landwehr
>> show me that an event 'xforms-invalid' is dispatched when an invalid 
>> data is changed to a still invalid value.
> 
> 
> Is that what the spec says? It turns out that yes, in the proposed 
> second edition: "Dispatched in response to: an instance data node
either 
> changing and *being* or becoming invalid.", plus all of "4.3.4 The 
> xforms-refresh Event".
> 
> It would be interesting to know the rationale behind resending MIP 
> events whenever the value changes, even if the properties associated 
> with the value have not changed. Somebody who knows, please?

I am re-reading the spec (proposed 1.0 2nd ed.), and I notice that under

"4.3.4 The xforms-refresh Event", it says:

"If the xforms-value-changed event is marked for dispatching, then all 
of the appropriate model item property notification events must also be 
marked for dispatching (xforms-optional or xforms-required, 
xforms-readwrite or xforms-readonly, and xforms-enabled or 
xforms-disabled)."

The above mentions all the MIP events, except xforms-valid or 
xforms-invalid. Is this a voluntary omission? If so, it would seem to 
say that if a value changes, but the MIP doesn't change, then there is 
no need to send xforms-valid and xforms-invalid.

Quid?

-Erik

Received on Friday, 28 October 2005 08:35:25 UTC