Here is one issue, however, that exemplifies the W3C and their long term goals and how they actually have some meaning in real world application.

Anyone remember tables? Tables for layout, I mean. It was easy, simple–the comfortable way–especially for us non-experts. But as technology and information delivery devices have become more popular and more diverse, tables just didn’t cut it any more. They are clunky, and inflexible.  The W3C understood this and discouraged tables as layouts. We baulked and moaned and didn’t really have the vision to see how we could possibly design without tables as layout.

Resistantly (because no one likes extra work, right), we realized we better get on board and figure out how to do page layouts without tables.

Then came a whole host of problems. Exactly how can we achieve the columnar effects of a table? Without getting into details, do a google search for “CSS column layout” and see how many hits you get.

It was an adjustment that some resisted, but the W3C was right. We needed to get away from tables for layout. However, they didn’t offer much by way of alternatives–well, not any that non-experts or non-web-masters could easily follow.

Finally comes the W3C standard that works. And you don’t have to be a web guru to figure it out. How difficult is it to understand “column-width: 13ex;”  “column-count: 2;” and “column-gap: 1ex;”?  Even if you only play around with web pages and know only basic CSS, this is not very difficult to understand at all. Think of the power now that is given to the non-expert in making pages that look as professional as any magazine or newspaper, and without all the hassles of whatever your favorite way of doing columns is right now.  And such a standard will ensure that your columns work across information devices.  Bravo!

SEE the article I read that prompted this post (there were others, I just chose this one for the examples–which, btw, only work in Mozilla or Safari, I think).

http://www.quirksmode.org/css/multicolumn.html

An Xquery article by Kurt Cagle.

However, one doesn’t need a switch/case at all but can rely on “relevance” to get the same effect, without as much coding, and by only using one, instead of two, triggers. Credit for this approach goes to the xforms administrator at xforms.org.

There is also a tip on how to toggle through a slideshow. Check it out, I really learned something. http://xforms.org/index.php?topic=177.0

I’m posting my own code here just for my own personal reference, but take a look at the other code on that site as well, –the administrator is an xforms expert, so you’ll learn much.

<?xml version="1.0" encoding="UTF-8"?>
<h:html xmlns:h="http://www.w3.org/1999/xhtml"
xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:xf="http://www.w3.org/2002/xforms">
<h:head>
<h:title>Test</h:title>
<xf:model id='mod2'>
<xf:instance id='inst2'>
<data xmlns="">
<toggleState>0</toggleState>
<toggleOn/>
<toggleOff/>
</data>
</xf:instance>
<xf:bind  nodeset='toggleOn' relevant='//toggleState = 1'/>
<xf:bind  nodeset='toggleOff' relevant='//toggleState = 0'/>
</xf:model>
<h:style type="text/css"><![CDATA[
fieldset {width:200px;paddding:5px;border:solid 1px blue;}
legend {padding:5px;background-color:red;color:white;font-weight:bold;border:outset 2px red;}
legend:active {border:inset 2px red;}
]]></h:style>
</h:head>
<h:body>
<xf:output ref="//toggleState"/>
<h:fieldset id="fs1">
<h:legend>
<xf:trigger appearance="minimal">
<xf:label>Toggle Set</xf:label>
<xf:setvalue model='mod2' ref='//toggleState'
value="if(number(.)=1,0,1)" ev:event="DOMActivate"/>
</xf:trigger>
</h:legend>
<xf:group model='mod2' ref='//toggleOff'>
</xf:group>
<xf:group model='mod2' ref='//toggleOn'>
<h:p>Something here .... yada yada</h:p>
</xf:group>
</h:fieldset>
</h:body>
</h:html>

One thing you will notice, however, is that as you become more versed in xforms, you’ll find less and less need to rely on the DOM for data manipulation. One might, then, want to get well versed in both xpath and xforms before putting time into learning how to manipulate data with the DOM. (Come to think of it, I think you can do just about everything you need using PHP with Xpath, so that may just obviate the need for the DOM–but I’ll let some expert comment on that if they like).

[ note: Xforms uses xpath expressions; however, don't confuse learning xpath with learning xslt which also relies on xpath expressions. check out http://www.w3schools.com/xforms/xforms_xpath.asp]

I handle my data with arrays simply because I am a professor of English who has a lot of demands on his time that aren’t computer related, and since I’m handling my own personal data when programming, and I know my own schema, I have simply found it the best way to get involved with xforms and xml now without having to learn anything other than basic DOM manipulation (I’m also an old time procedural language fella’ who tends to think in old ways, so it is only natural that I would take a procedural approach to doing things until I can master the more declarative approaches). And I wish like heck I had more time to get all I could out of xforms and xpath, the more I learn about xforms, the more I see it’s power and simplicity.

You’ll also need to look at No files selected (using xf:bind and relevant) –the point of that post not being the file selection but the ability to hide any portion of your document, dependent on some condition, by combining the use of xforms-group, xforms-bind, and xforms-relevant. We’ll use all these in this solution.

First, let’s get to the problem. I was using the css absolute position to allow my menu box to drop down over other elements. Then I decided to have two such boxes do the same thing. There is only one problem. When two absolute positioned divs are next to each other, either side-by-side or one above the other in a column style, the second div text won’t hide. A picture is worth a thousand words, so here:

in columnar fashion:

or in bar fashion

and sometimes you get this, which is actually pretty cool, but not very useful:

Sticking with the bar menu, here’s how the divisions are set (this is the structure, not the exact coding):

<h:div style="padding:1ex; position:relative;">

<h:div style="position:absolute; left:1ex; top:2ex;">
<!-- ******** Main Menu *************-->
<h:div>

<h:div style="position:absolute; left:22ex; top:2ex;">
<!-- ******** View File List ******* -->
<h:div>

<h:div>

..... the rest of the xhtml+xforms doc

</h:html>

The best way to overcome this problem is to encase the ‘view file list’ division inside an xf:group that depends on the relevancy of another element. By doing so, when the dependant element becomes some other value than 1–in our case, zero– then the ‘view file list’ will simply disappear.
code:

<h:div style="padding:1ex; position:relative;">

<h:div style="position:absolute; left:1ex; top:2ex;">
<!-- ******** Main Menu *************-->
<h:div>

<xf:group model='mod2' ref='//fileListOn'>
<h:div style="position:absolute; left:22ex; top:2ex;">
<!-- ******** View File List ******* -->
<h:div>
   </xf:group>

<h:div>

I have decided that in all my xhtml+xforms to keep a model “mod2″ that is set aside exclusively for controlling controls. So in our mod2, as shown in my earlier posts, we’ll add this (ignore all but the highlighted):

<xf:model id="mod2">
<xf:instance id="inst2">
<data xmlns="">
<uplSelected>0</uplSelected>
<uplTriggerOn/>
<uplTriggerOff/>
<delFileSelected>0</delFileSelected>
<delTriggerOn/>
<delTriggerOff/>
         <vwFileList>1</vwFileList>
<fileListOn/>
</data>
</xf:instance>

<xf:bind  nodeset="uplTriggerOn" relevant="//uplSelected = 1"/>
<xf:bind  nodeset="uplTriggerOff" relevant="//uplSelected = 0"/>
<xf:bind  nodeset="delTriggerOn" relevant="//delFileSelected = 1"/>
<xf:bind  nodeset="delTriggerOff" relevant="//delFileSelected = 0"/>
   <xf:bind  nodeset="fileListOn" relevant="//vwFileList = 1"/>
</xf:model>

Notice that vwFileList is initially set to 1, this allows for an initial view of the ‘view list file’ division.

So we need to set up how the vwFileList value will get changed from 1 to 0, making the vwFileList value a zero, hence, making the fileList On element irrelevant, hence, hiding the xf:group for ‘view list file’ division. We’ll do this in our ‘main menu’ Switch/case section. This way when someone clicks on the main menu to open it, the ‘view file list’ will disappear. When they click on it again to close it, the ‘view file list’ will reappear. (I left out the styling below–keep in mind that the filedset width of ‘main menu’ and ‘view file list’ is set at 24ex )

<xf:switch>

<xf:case id='menuShut'>
<xf:trigger appearance='minimal'>
<xf:label>:: Main Menu ::</xf:label>
<xf:toggle case='menuOpen' ev:event='DOMActivate'/>
                <xf:setvalue ev:event="DOMActivate" model="mod2"
ref='//vwFileList' value="'0'"/>
</xf:trigger>
</xf:case>

<xf:case id='menuOpen'>
<xf:trigger appearance='minimal'>
<xf:label>:: Main Menu ::</xf:label>
<xf:toggle case='menuShut' ev:event='DOMActivate'/>
                <xf:setvalue ev:event="DOMActivate" model="mod2"
ref='//vwFileList' value="'1'"/>
</xf:trigger>

.... the MENU contents here .....
.... the MENU contents here .....
</xf:case>

</xf:switch>

The outcome will look like this, notice the disappearing ‘view file list’ :

But what if they forgot to click on a file before clicking the load or submit button? It’s unlikely, but if someone happens to be using this particular page frequently in one sitting, it’s not entirely unlikey either, and in such a case they’ll get a nasty error message which will freak them out (especailly if it were a situation where they were saving or deleting –they wouldn’t really know what happened).

So first let’s put an extra model in our xforms (you could just add an extra instance to your current model, I suppose, but It’s much easier, from my perspective, to reference a second model than a second instance–besides, currently, mozilla is having some trouble reading the xml instance when there are multiple instances). So here it is:

<xf:model id=”mod2?>
   <xf:instance id=”inst2?>
      <data xmlns=”">
         <delFileSelected>0</delFileSelected>
         <delTriggerOn/>
         <delTriggerOff/>

         <vwFileSelected>0</vwFileSelected>
         <vwTriggerOn/>
         <vwTriggerOff/>
      </data>
   </xf:instance>

   <xf:bind  nodeset=”delTriggerOn” relevant=”//delFileSelected = 1?/>
   <xf:bind  nodeset=”delTriggerOff” relevant=”//delFileSelected = 0?/>
   <xf:bind  nodeset=”vwTriggerOn” relevant=”//vwFileSelected = 1?/>
   <xf:bind  nodeset=”vwTriggerOff” relevant=”//vwFileSelected = 0?/>
</xf:model>

For now, we’re going to ignore the “del….” parts of the model, I just included it here so that you can see that this model could be built to handle several different types of situations. So let’s just focus on the vw (view) elements, like below:

<xf:model id=”mod2?>
   <xf:instance id=”inst2?>
      <data xmlns=”">
…
         <vwFileSelected>0</vwFileSelected>
         <vwTriggerOn/>
         <vwTriggerOff/>
      </data>
   </xf:instance>
…
   <xf:bind  nodeset=”vwTriggerOn” relevant=”//vwFileSelected = 1?/>
   <xf:bind  nodeset=”vwTriggerOff” relevant=”//vwFileSelected = 0?/>
</xf:model>

These elements are going to control my controls. Basically it is all set around the value of the “vwFileSelected” element. If the element’s value is zero, we’ll hide one control and show the other. If the element equals one, vice-versa.
We’ll do this by wrapping the controls with xf:group elements and each group element will refer back to vwTriggerOn or vwTriggerOff.
Notice the xf: bind element. The vwTriggers depend on this bind–and hence, the value of vwFileSelected. If someone doesnt’ click on a file in the xf:select1 control, then the vwTriggerOff will show because the vwFileSelected is initially set at zero.
Then, using xf:setvalue with event xforms-select inside the xf:select1 control, the vwFileSelected will be set to one and so the vwTriggers switch roles.
In this example the “view” button will appear unfocused until someone selects a file, then it will appear in full color.
As the images below will also show, it appears as if we have a single “view” trigger. But underneath the hood, they’re really two separate triggers which means, importantly, that even if someone attempts to click on it the trigger won’t work. Here’s the images:

Here’s the code–I left most of the styling out in order not to clutter the code, but you’ll get the same basic effect:

   <xf:select1 ref="viewFile" appearance="minimal">
      <xf:setvalue model=”mod2? ref=”//vwFileSelected”
                        value=”‘1?” ev:event=”xforms-select”/>
        <xf:label>Select a Form: </xf:label>

        <xf:itemset nodeset=”//file”>
          <xf:value ref=”@full” />
          <xf:label ref=”@text” />
        </xf:itemset>

    </xf:select1>(opens in new tab or window)

   <xf:group model=”mod2? ref=”vwTriggerOff”><h:p/>
      <xf:trigger appearance=”minimal”>
         <xf:label><h:span style="color:#dododo>
             View
         </h:span></xf:label>
      </xf:trigger>
   </xf:group>

   <xf:group model=”mod2? ref=”//vwTriggerOn”><h:p/>
   <xf:submit id="subm1zaz" class="subm"
      submission="xfviewstyle" appearance='minimal'>
      <xf:label>
        <h:fieldset style="color:#000033;">
        View
      </h:fieldset>
      </xf:label>
   </xf:submit>
   </xf:group>

/* as a footnote I tried this with xf:load as shown below,
but the trigger wouldn't activate regardless of the vwFileSelected value.
Don't know if it's a bad xpath reference on my part
(and I tried every path route I could think of) or a Mozilla bug.
You can see the code below is exactly like the above only substituting
xf:load control for xf:submit. If anyone has a clue let me know. */
   <xf:group model=”mod2? ref=”//vwTriggerOn”><h:p/>
      <xf:trigger appearance = “minimal”>
         <xf:label><h:span style="color:#000033>
               View
         </xf:label>
         <xf:action ev:event=”DOMActivate” ref=”//viewFile”>
            <xf:load  ref=”//viewFile” show=”new” />
         </xf:action>
      </xf:trigger>
   </xf:group>

At any rate, it works great with submit control as I tested it quite thoroughly and also use it with my delete files optoin as well.

An alternate solution, is to simply do away with the first xf:group (the fake “view” trigger) . In this case you’d have only the select box showing and then when someone clicked on a file, the “view” trigger would appear.

And yet another approach, if you like, you can add some text right below the trigger (not inside the trigger element but just below it) as such:

<h:span style=’font-size:105%;color:#800000?>
<xf:output model=”mod2? value=”if(//vwFileSelected != 1,’NO FILES SELECTED’,”)”/>
</h:span>

The above gives a single message that dissappears after a selection is made. However, you can have an alternate text in the xf:output like this:

…’NO FILES SELECTED’,’OK’ )”

If you have a deselect situation (and I saw no need for that in my viewing situation) make sure you set the xfFileSelected value back to zero so the “View” trigger loses focus again (and/or the ‘NO FILES SELECTED’ message reappears). In the situation of a select with apperance = ‘full’ just add this line inside the select or select1 along with the other setvalue.

      <xf:setvalue model="mod2" ref="//vwFileSelected"
                        value="'0'" ev:event=“xforms-deselect”/>

In my case, in my delete files situation, Mozilla won’t allow a deselect on an xf:select (multiple select) appearance=’minimal’, so I added this trigger right above my selection box. Notice that the value of my instance element is set to “” –nothing, and that the value of my “mod2? instance element is reset to zero.

<xf:trigger><xf:label>deselect choice/s</xf:label>
   <xf:setvalue ref="//deleteFiles" value=”" ev:event=”DOMActivate”/>
   <xf:setvalue model=”mod2” ref=”//delFileSelected” value=”0? ev:event=”DOMActivate”/>
</xf:trigger><h:br/>

Again,what’s cool about this it that we never have to make a trip to the server nor lose the focus of our page while double checking that a control has been, or not been, selected–while simultaneously controlling the active state of the displayed trigger.

[ on a different note, if your interested how I got the "legend" look on a switch/case, see Xforms: The Legendary Toggle ]

<!-- ********** SWITCH/CASE TOGGLE***************************** -->
<!-- Lorem ipsum -->
           <xf:switch>
               <xf:case id="shut">
                  <xf:trigger appearance="minimal">
                     <h:span style="color:olive; font-size:95%;">
                     <xf:label>:: toggle ::</xf:label>
                     </h:span>
                     <xf:toggle case="open" ev:event="DOMActivate"/>
                  </xf:trigger>
               </xf:case>
               <xf:case id="open">
                  <xf:trigger appearance="minimal">
                     <h:span style="color:gray; font-size:95%;">
                     <xf:label>:: toggle ::</xf:label>
                     </h:span>
                     <xf:toggle case="shut" ev:event="DOMActivate"/>
                  </xf:trigger>

                  <h:div style="color:olive; font-size:95%;">
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum
dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt mollit anim id est laborum.
                  </h:div>

               </xf:case>
            </xf:switch>

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

For another approach with the same effect see A better Legendary Toggle