- From: Erik Bruchez <erik@bruchez.org>
- Date: Tue, 25 Oct 2005 18:49:48 +0200
- To: www-forms@w3.org
Thanks Andy. It makes sense, and unfortunately (for you and I) falls
into the category "here is a way, but it's really a dirty hack" ;-)
We have done exactly the same things by placing a single event handler
higher up the XHTML, to catch all the validation events of a group of
controls, and incrementing vs. decrementing a counter. This takes about
10-15 lines of extra code, including the extra instance. I think that
ideally such a functionality should be achieved with a single attribute.
So far, we are taking branch #2 in my original question!
-Erik
andyh@collegenet.com wrote:
>
>
>
>
> Erik,
>
> This is what we do...
>
> We have an errors instance:
>
> <xf:instance id="iErrors">
> <errors xmlns="">
> <total>0</total>
> <fields>
> <field id="USERNAME">0</field>
> <field id="FIRST_NAME">0</field>
> <field id="LAST_NAME">0</field>
> <field id="EMAIL_ADDRESS">0</field>
> <field id="PASSWORD">0</field>
> </fields>
> <save/>
> <nosave/>
> </errors>
> </xf:instance>
>
> <xf:bind nodeset="/errors/total" calculate="sum(../fields/field)"/>
> <xf:bind id="bndSave" nodeset="/errors/save" relevant="../total = 0" />
> <xf:bind id="bndNoSave" nodeset="/errors/nosave" relevant="../total > 0"
> />
>
> that records the state of each field we need to validate.
>
> Each of those controls have event handlers for xforms-valid and
> xforms-invalid to set the error count to 0 or 1 respectively.
> eg.
>
> <xf:input ref="USERNAME" class="SmallTextField" id="f001">
> <xf:label>Username:</xf:label>
> <xf:alert>Please supply a unique username</xf:alert>
> <xf:setvalue model="mErrors"
> ref="instance('iErrors')/fields/field[@id = 'USERNAME']" value="1"
> ev:event="xforms-invalid"/>
> <xf:setvalue model="mErrors"
> ref="instance('iErrors')/fields/field[@id = 'USERNAME']" value="0"
> ev:event="xforms-valid"/>
> </xf:input>
>
> Finally we have two trigger elements bound to bndSave and bndNoSave. Our
> styling hides non-relevant controls so only one of these buttons is visible
> at any point in time. The bndNoSave version has the HTML attribute
> disabled="disabled" on it so that the button truly looks disabled.
>
>
> Now formsPlayer has just introduced an XPath extension function
> fpext:valid(node-set) [1] that returns true or false of whether a node is
> valid or not, and this could be used in calculations instead of the event
> pattern above.
>
>
> Andy
>
> [1] http://www.xforms-wiki.com/bin/view/Main/XformsXpathFunctionsExtension
>
>
>
>
>
> Erik Bruchez
> <erik@bruchez.org
> > To
> Sent by: www-forms@w3.org
> www-forms-request cc
> @w3.org
> Subject
> Disabling a button based on
> 10/25/2005 08:32 validity
> AM
>
>
>
>
>
>
>
>
>
>
> All,
>
> I am having trouble figuring out the solution to an extremely basic UI
> requirement: disabling a submit button, implemented either with
> xforms:submit or xforms:trigger, until certain fields have been filled
> out correctly by the user.
>
> Of course, you could leave the button always enabled. Upon XForms
> submission, if the submitted instance is not valid or has missing
> required fields, submission will fail, throw an xforms-submit-error,
> and you can notify the user of the failure. But from a usability
> perspective, this is usually a bad solution.
>
> So these are my questions:
>
> 1. How do people address this UI requirement today with XForms? Is
> there a way of doing this purely based on the XForms 1.0
> specification? If not, are there workarounds? For example, we have
> played with counting xforms-valid and xforms-invalid events,
> clearly a quite heavy solution.
>
> 2. If the answer to #1 above is "no" or "here is a way, but it's
> really a dirty hack":
>
> 2.1. Is the WG working on addressing this? (I should talk with
> Sebastian but it doesn't hurt to ask this publicly.)
>
> 2.2. Are there extensions suggested or implemented by existing
> XForms engines that address this?
>
> Thanks,
>
> -Erik
>
>
>
Received on Tuesday, 25 October 2005 16:50:06 UTC