W3C home > Mailing lists > Public > www-forms@w3.org > October 2005

Re: Disabling a button based on validity

From: David Landwehr <DLandwehr@novell.com>
Date: Fri, 28 Oct 2005 14:59:49 +0200
Message-Id: <43622ED5020000510000DCEA@emea1-mh.id2.novell.com>
To: <erik@bruchez.org>,<Erik Bruchez <erik@bruchez.org>, <www-forms@w3.org>

Hi Erik,

I must have forgotten to document the valid function for exforms.org or
I noticed the problem when I wrote it and then forgot to do something
about it (I wrote the text some time ago) :(

You are correct that using the exf:valid function in the mips will be
problematic since it will be delayed one xforms-recalculate. However the
function will still be useful in the UI because that is updated in
xforms-refresh. So in the use case we have an XPath expression would
state:

<xforms:trigger ref="self::node()[exf:valid(/where/the/tree/is)]"/>

That trigger should behave as irrelevant, so it is essential the same as
having a relevant="exf:valid(/where/the/tree/is)"

Best regards,
David

>>> Erik Bruchez <erik@bruchez.org> 28-10-05 6:00 >>>

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 13:00:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:02 GMT