Coming Up for Air

Making Tables Harder Than They Need To Be

I know you’re not supposed to do this, but sometimes it’s just easier. Sometimes I use tables to layout out my forms. Especially for big forms, it’s just easier to put things in a table than deal with labels, CSS, etc. Right or wrong, I do it from time to time, but, thanks to David Geary, I just learned that I make it harder on myself than it needs to be. The sad thing is that I’ve known about this solution for years now, but never put two and two together.

Typically, my form my look something like this:

<table>
<tr>
    <td>#{msg.label1}</td>
    <td><h:inputText value="#{myBean.field1}"/></td>
</tr>
<tr>
    <td>#{msg.label2}</td>
    <td><h:inputText value="#{myBean.field2}"/></td>
</tr>
// ad naseum
</table>

JSF, though, has a nicer approach, which David used in his article: h:panelGrid. This component will take each child component and put it in a table. The number of columns in the table is controlled by the columns attribute (of course, there is more to this component than just this option). My table, then would look like this:

<h:panelGrid columns="2">
    #{msg.label1} <h:inputText value="#{myBean.field1}"/>
    #{msg.label2} <h:inputText value="#{myBean.field2}"/>
</h:panelGrid>

The component then handles the creation of the table, rows, and cells automagically for me. Following David’s example, I put the label and input field on the same row, as that helps me visualize the resulting table better, but it’s not necessary. If you need more than one component in a cell, you simply wrap those in a h:panelGroup:

<h:panelGrid columns="2">
    #{msg.label1}
    <h:panelGroup>
        <h:inputText value="#{myBean.field1}"/>
        <br/>
        #{msg.helpText1}
    </h:panelGroup>

    #{msg.label2}
    <h:panelGroup>
        <h:inputText value="#{myBean.field2}"/>
        <br/>
        #{msg.helpText2}
    </h:panelGroup>
</h:panelGrid>

Fancy! Now I need to give some thought to a component that will help layout forms The Right Way!

Popularity: 8% [?]

7 Comments to Making Tables Harder Than They Need To Be

  1. May 14, 2009   #

    ” Right or wrong, I do it from time to time”

    It’s wrong :razz: . Forms are not tabulatory data. What’s wrong with:

    markup:

    foo

    css:
    div.field {
    clear: both;
    }
    label {
    float: left;
    width: 10em;
    }

    ?

  2. May 14, 2009   #

    escaped my markup :(

    markup:

    [div class='field']
    [label]label[label] [input /]
    [/div]

  3. May 15, 2009   #

    I know many people agrees that using table is a lame way to design a messy form. Cool kids use

    but I am old school when comes to design a form that has couple dozen fields. I feel, table gives me more control and I can get around with a table lot quicker than fiddling with
    /css or . I have tried to layout my form and it seemed to be I had hard time put things in right place using than a simple html table.
  4. May 18, 2009   #

    It is wrong to use tables to structure forms.
    Creating the CSS is more complicated on the first time, but once it is created, just use it.
    Moreover, the size of the pages when structured with tables becomes much bigger :) .

  5. June 5, 2009   #

    It’s wrong to tell someone how to design their application. As Jason cited, tables are often much faster and therefore save you time and money trying to get the CSS right. Don’t rationalize money spent when you don’t know the situation. CSS takes a long time to get right, especially for those that don’t have extensive knowledge of it or a cheat in their back pocket.

    So +1 for Jason.