- From: Erik Bruchez <erik@bruchez.org>
- Date: Fri, 28 Oct 2005 14:00:07 +0200
- To: www-forms@w3.org
David Landwehr wrote: > 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. David, Thanks for the precisions. I agree with your assessment: I don't think it is necessary to revise the way events are dispatched, at least not just to implement this use case; counters or setters are not an ideal solution; the functionality should IMO follow the semantics of xforms:submission, i.e. the property should reflect whether the instance or subset thereof (single-node binding) can be submitted or not as per section 11.1. BTW I don't see a exf:valid() function in exforms.org: only exf:relevant(), exf:readonly(), and exf:required(). I noticed this a few days ago and was going to comment about it. Now isn't there a problem with such a function, as revalidation occurs after the other MIPs have been computed, and if, for example, you decide that an xforms:submit control must be relevant under the condition that a node is valid, then at the moment the relevant MIP is evaluated, revalidation hasn't yet occurred? -Erik
Received on Friday, 28 October 2005 12:00:17 UTC