W3C home > Mailing lists > Public > www-forms@w3.org > April 2002

RE: xforms:alert event

From: Tomayko, Ryan <Ryan_Tomayko@stercomm.com>
Date: Wed, 10 Apr 2002 07:34:26 -0400
Message-ID: <5FD6397E455FD4118BAE00062938354002C90551@scidubmsg02.amr.stercomm.com>
To: www-forms@w3.org
I've also noticed a gap here and have actually resorted to a proprietary
solution in our implementation.

Basically, the problem I'm seeing and as Jérôme described is that you can
have multiple isValid constraints associated with a single node, but only a
single human readable description of why the node is invalid. 

We've interpreted the spec as follows to come to this conclusion:

An isValid expression evaluating to false means the node is invalid. An
isValid expression evaluating to true means the node is not invalid. This
doesn't mean it's valid, just that it's not not valid (read it again). Put
simply, for a node to be valid, all isValid constraints must return true for
that node.

This works really well because it allows us to apply multiple rules to a
single node (e.g. phone number is proper format and it's in the 555 area
code). However, we want to be able to display different messages for each
failed validation. In order to accomplish this, we've added an attribute to
the <xforms:bind> element that allows a "reason message" to be attached to
each isValid constraint. This message is displayed when that isValid
constraint returns false.

Problems with this method are 
a.) non-standard 
b.) can't use xlink:href/ref attributes to get localized versions of error
Otherwise it works fairly well.

This is only one of the issues we're seeing with the way validation is
currently handled. Another issue is with invalid fields that do not have a
visible form control. It's possible to calculate a value on a node that does
not have an associated UI control, so there's nowhere to send the alert. The
next is the case of having multiple controls referencing the same node.
Where should the alert be specified? For instance, on a PO form we have a
menu selectOne showing catalog'd goods that map to SKU numbers and an input
where the SKU can be entered directly. Both are bound to the same sku
element. Both of these are pretty rare but still illustrate a gap. 

IMHO, validation has been designed too heavily from the UI layer. I think
some of this functionality should be rethought from the model layer. The
problem seems to be that validation effects both the data and UI almost
equally so finding middle ground may be hard. Validity of XML data is
completely UI independant and I think the messages that go along with the
rules should be declared as part of the model.

- Ryan

-----Original Message-----
From: Jérôme Nègre [mailto:jerome.negre@e-xmlmedia.fr]
Sent: Wednesday, April 10, 2002 4:47 AM
To: www-forms@w3.org
Subject: xforms:alert event


according to chapter 4.3, an alert event is dispatched for each invalid form
control each time a valueChanged event is dispatched.

This implies that an alert window will pop-up many times for a single form
control, although its value doesn't change.

Is it the expected behaviour? I'm affraid it's not very user friendly.

Received on Wednesday, 10 April 2002 07:39:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:05 UTC