I'm forwarding this note from the Mozilla XForms implementation list.
I encouraged the author to send a note to www-forms but apparently he
didn't join first; he sent this second note instead.

-----Original Message-----
From: dev-tech-xforms-bounces+leigh.klotz=xerox.com@lists.mozilla.org
On Behalf Of dr.cw.ray@gmail.com
Sent: Saturday, June 07, 2008 5:15 AM
To: dev-tech-xforms@lists.mozilla.org
Subject: xforms-hide at w3c

I sent an email to the w3c forms group but it didn't seem to make the
list, or at least, if somebody did recieve it I didn't get an email
acknowledgement nor could I find it on the web pages list.

I was just going to let my suggestion die, but then I ran into another
situation from a user over at xforms.org that indicates a need for some
simplicity in showing and hiding sections of a form.  He has 26 xml
files with 26 corresponding instances all representing a single letter
of the alphabet. He needs to simply show or hide all the entries
associated with each letter/instance (each xml file is a word list).  He
could do this using  an xforms-hide and xforms repeat for each word
list.  To be short, it's another case where a simple xforms- hide
element could make the job a lot easier.

<xforms:hide hidden="on" trigger="minimial>
     <xforms:repeat  ..... for the letter A ... etc </xforms:hide>
<xforms:hide hidden="on" trigger="minimial>
     <xforms:repeat  ..... for the letter B ... etc </xforms:hide>

At any rate, If Leigh or anyone else happens across this before the next
meeting, I'm posting a copy of my email, since I can't tell if it made
the list or not. Please put forward my suggestion.

I have spent the last two years building an Xorms form-maker, a mini CMS
for educational purposes, and  a  forum/blog application using only
Xforms (and php server-side).

This experience has led me to believe that there might be one control
you could add to your Xforms specs that would save a lot of the
verbosity we naturally get with xforms. For lack of any other name, for
now I'll call it an xforms-hide control. It would look something like

<xforms:hide hidden="on" trigger="minimal">
       ... data or form elements here ...

Let me begin by simply posting a small snippet of code that exemplifies
exactly the behavior of the control I'm proposing above using the
switch/case method.

<!-- ********** SWITCH/CASE TOGGLE***with empty case****** -->
<!-- Lorem ipsum -->

             <xf:case id="shut">
                <xf:trigger appearance="minimal">
                   <xf:label>:: toggle ::</xf:label>
                   <xf:toggle case="open" ev:event="DOMActivate"/

             <xf:case id="open">
                <xf:trigger appearance="minimal">
                   <xf:label>:: toggle ::</xf:label>
                   <xf:toggle case="shut" ev:event="DOMActivate"/>
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua.


<!-- ******* END SWITCH/CASE TOGGLE***************************** -->

Notice that the first case is empty (holds no content or forms
This simple code acts as a single toggle for hiding and un-hiding
sections of a form. The section can be a small text message or even a
large section containing a sub-form.

Using the switch/case method looks good on the surface in this small
scale example, but when you build a large application and you end up
with either several switch/cases that hide large subforms, or several
nested switch/cases hiding subforms, the form can become quite

Of course, an alternative to the Switch/case method above would be to
use xforms-binds with @relevance that could hide and un-hide certain
sections of a form using a xforms-trigger with event-DOMActivate in
combination with a xforms-setvalue which would make an element relevant
or non-relevant and therefore the corresponding section as well. But in
large scale applications, this also encumbers the form.
In such cases, one has to not only build a separate instance in the
model to control the controls, but also to bind each of the necessary
elements of the new instance for each and every separate section one
desires to hide.

Again, it becomes quite unwieldy the more sections or nested sections
one desires to hide. I also think the above approach makes keeping up
with how the xpath pointer acts difficult, therefore making it more
difficult to get your xpath references correct.

My suggestion would be to take the exact behavior of the switch/case
code posted above and simplify it into a single xforms-hide control.
Something like this.

<xforms:hide hidden="on" trigger="minimal">
       ... data or form elements here ...

where hidden="on" initially displays only a trigger and hidden="off"
initially displays the contents along with a trigger for "hiding" the
content.   The @trigger attribute would act the same as the
@appearance attribute in an xforms-trigger.

Thank you for your consideration.
Carl Ray, Jr., Ed.D.
Fortune Institute of Technology, Taiwan
dev-tech-xforms mailing list

Received on Monday, 16 June 2008 16:49:20 UTC