W3C home > Mailing lists > Public > www-forms@w3.org > February 2007

Re: Question about E31in relation to 'Non-selected Cases'

From: John Boyer <boyerj@ca.ibm.com>
Date: Thu, 15 Feb 2007 13:49:38 -0800
To: Nick_Van_den_Bleeken@inventivedesigners.com
Cc: www-forms@w3.org, www-forms-request@w3.org
Message-ID: <OFB1404BA7.893AC060-ON88257283.00775406-88257283.0077E6EF@ca.ibm.com>
Hi Nick,

Yes, you're right that switch/case does not solve this use case.  Whether 
it used to or not depends on one's perspective.  For example, my 
interpretation  of switch/case has always been that you get only one case 
at a time and the others are dead or at best zombies to be ressurected by 
a toggle spell. :-)  This is consistent with switches we have in everyday 
life but also everyday other programming languages.

Anyway, the thing you are describing is not a UI switch but rather a 
visual effect that should be governed by the presentation layer.  You do 
want several groups of controls that are all relevant and have proper 
XForms behaviors. You just only want to see one group at a time, so you 
have to use the visibility property or the display property to control 
that.

John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Nick_Van_den_Bleeken@inventivedesigners.com 
Sent by: www-forms-request@w3.org
02/14/2007 12:30 AM

To
www-forms@w3.org
cc

Subject
Question about E31in relation to 'Non-selected Cases'







Hi,

We have the following use case, and I was wondering if my conclusion is 
correct (that we no longer support this use case after issuing E31 
http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E31)

Use Case: The user wants to use a switch styled as a Tab pane and wants to 

indicate on the 'tab selection button' if there are 'problems' on that tab 

(req1). He also wants to show a list of problems when the user hits a 
validate trigger(req2).


How we implemented req2: Add an extra instance with messages, and an 
attribute on the message element to indicate if the message is applicable. 

Attach listeners to the controls for xforms-valid and xforms-invalid 
events that change the attribute to indicate if the message is applicable. 

Use an xforms:repeat to show all applicable messages when the user hits 
the validate button.

How we implemented req1: We can use the applicable attributes of the 
messages we needed for req2 and use those on a ref of group that 
shows/hide a problem icon on the 'tab selection button'.


At first this solution seems to work, but because :
1) due to 'When a form control becomes non-relevant, it must receive event 

xforms-disabled and then the XForms action handlers that are listening for 

events on the non-relevant form control must be disabled.' the event 
listeners that update the applicable attribute are disabled for all not 
selected cases, even if they are placed outside the non-selected case.

2) When there is an input on case 'b' which has a cosntraint that uses a 
value specified in another case let say 'a'

3) Fill in case 'a', then fill in case 'b' so that both cases are valid. 
Go back to case 'a' and change the value of the control so that the 
constraint of one of the inputs on case 'b' will fail
--> The listener that changes the applicabilty won't be triggered until 
the user goes to case 'b'

This may seem as a border case, and a badly designed form, but if you are 
trying to fill in big real life forms, this 'border case' can not be 
circumvented.

Does anyone has a solution that satisfies the two requierements of this 
use case and works in standard XForms?

Thanks in advance,

Nick Van den Bleeken  -  Research & Development
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivedesigners.com


--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer
Received on Thursday, 15 February 2007 21:50:47 GMT

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