26
At long last, the Woodstock component set is finally here. At IEC, we have been anxiously awaiting its release for quite some time now, as we’ve been hoping to make use of the sortable data table component it offers, which we have now done. Having done it, allow me to show off the component a bit, as well as explain what I had to do make things work. It’s not hard, necessarily, just different enough to give one pause at first glance.
Table of Contents
- Setting up your environment
- The Table
- Displaying Data
- Sorting Data
- Filtering Data
- What It Looks Like
- Closing
Setting up your environment
The first thing you will need to do, obviously, is add the required jars to your project:
- dataprovider.jar
- dojo-0.4.1-ajax.jar
- jsf-extensions-common-0.1.jar
- jsf-extensions-dynamic-faces-0.1.jar
- json.jar
- prototype-1.5.0.jar
- webui-jsf-suntheme.jar
- webui-jsf.jar
To make things look pretty (and who doesn’t), you will also need to configure the Woodstock theme servlet:
Note that if you are using Facelets (which all of these examples will be), you will need to take a look this Woodstock issue. If you don’t want to checkout the sources, apply the patch, etc, here is the tag library file which you can place in /META-INF/ in your class path.
With that done, you will need to declare the Woodstock namespace on your page:
Of course, XML being what it is, xmlns:w="http://www.sun.com/webui/webuijsf" will have to be repeated on each page that uses a Woodstock component. I should also note that, while I was using “webuijsf” as the Woodstock examples suggested, I have started using “w” as it’s much smaller (and have updated this entry to reflect that). Having done that, you will now need to change your Facelets template/template client (or JSP header include, etc), changing <head> to <w:head>. This is necessary, as this is how the various JavaScript and CSS files required by Woodstock are included.
Alternately, you can use the themeLinks component:
The Table
We’re now ready to put a table on the page. Here’s a snippet from the application in which I’ve implemented the table:
At first glance, that’s quite overwhelming, and I’ll be the first to admit that I don’t understand everything that’s going on there, but I’ll try convey what I do understand.
For good or bad, this sample does both sorting and filtering. The properties on should be fairly self-explanatory. The actionsTop facet allows me to insert arbitrary markup into the area by that name in the table header. In this example, it is through this area that I’m able to perform various actions against the selected rows in the table: assign an engineer or refresh the table (i.e., clear any filters and reload the data the database).
Displaying Data
Finally, we come to the heart of the table, the tableRowGroup. This is the point at which I had to smile and nod, and just do what I was told. The TLD docs have this to say of this component:
Note that we bind this component to a property on the managed bean. This is where things get really…interesting. If you were to look at the example source code or the TLD docs for the table, you would find a number of helper classes, such as Group, Filter, and Select. If you are like me, your first inclination is to skip using these classes, hoping to simplify things a bit. Don’t. In fact, I took these classes and tweaked them a bit to make them more generally usable and bundled them in a utility library that we can use. If you’d like to use these classes, the complete source can be downloaded here. You can browse the source to see what all Group does, but one of its most important functions is to create the TableDataProvider the component will need. The easiest way I have found, which you will see in the class, is to wrap a List of my model objects in an ObjectListDataProvider:
Now that we’ve bound the data to the tableRowGroup, we need to display the data on the page. In the example above, I have two columns: one has a checkbox for selecting a row, and the other shows the assigned engineer. Again, this is somewhat of a black box for me, but as best as I can make out, the “select” column has a selection ID that will be used by the table’s JavaScript to manage selected rows. Note the the value of the selectId matches the id of the checkbox component. The checkbox itself has few properties to note. The first is the selected and selectedValue attributes, which are bound to methods on the Select object (owned by the Group object) that determine whether or not a given row has been selected. The third property is the onClick (note the case) property. The JavaScript referenced here is used to update the table to reflect the selected of the row associated with the checkbox (From the TLD Docs: “The JavaScript setTimeout function is used to ensure checkboxes are selected immediately, instead of waiting for the JavaScript function to complete.”):
Sorting Data
The next column in the table is a sortable column. While most of the markup here is straightforward, note the alignKey and sort properties. These columns indicate the field on which to sort when the user selects that column. I am uncertain as to whether or not they have to be the same, but I’ve always seen them that way, so that’s the pattern I’ve followed. It is also probably important to point out how data is retrieved from the DataProvider. In the staticText component, you’ll see the value is set to #{unit.value.assignedTo}. The variable unit is the sourceVar defined in the table setup, and value is a method on the DataProvider that returns (in our case) the object for the given row.
Filtering Data
Filtering is also enabled on our table. The filter facet is where I am able to specify the filters I’d like to be able to apply to the table. Due to a JavaScript issue I have yet to track down (which may or may not be related to my nascent Facelets support), my implementation here is a bit different from the Woodstock examples. Here is the source for filterMenuChanged:
It basically checks for the special option element Woodstock adds to determine if a custom filter is being requested (which causes the filter panel to be displayed), or if the “show all” option was selected, which will clear the filter. Note that this JavaScript is not optimal and has changed a fair amount as my understanding of the component has grown, and will likely do so again. Ideally, I’ll solve the JavaScript error that prompted this so that this can go away.
The next item of interest is the filterPanel facet, which is display when the user selects the “Custom Filter” option. The markup here pretty simple, in that all I have are a number of custom filters (though I’ve shown only one) that are nothing more than a label, an appropriate UIInput component, and a button. The only thing really noteworthy is the JavaScript used to apply the filter. Via EL, we’re taking the value entered or selected by the user, and setting that on a property on the Filter class (which I added to the Sun-provided class to make things more reusable). Since every field on the form will get set on the managed bean referenced via its EL, we can’t have them all pointing at the same property. To solve this problem, I use some simple JavaScript to copy the value in which I’m interested to a hidden field, which is the only one assigned to the desired property. I also use a to set which field should be filtered:
The source for applyCustomFilter is
When the form submits, the appropriate properties on the Filter object are set, and the filters are applied to the DataProvider:
What It Looks Like
Here is a screen shot from the application from which this table was taken. It shows the rows sorted by the “Assigned To” field, a row is selected, and the custom filter panel is displayed:

Closing
And that’s “all” there is to it. I’ve worked with (and on) a fair number of JSF components, but this is likely the coolest with which I’ve had personal experience. The “coolness” comes at a cost, though, in that the component can be difficult to grasp at first. Hopefully, this “little” will flatten the learning curve just a little bit. And while you’re playing with the table, be sure to check out some of the other Woodstock components. They did a great job.
As a side note, many thanks to Ken Paulsen (of JSFTemplating and Glassfish admin console fame) for answering all of my questions, regardless of how silly they seemed. My employer, IEC (namely, my boss Mitch, and not just because he reads this
) deserves many thanks as well for giving me the time to add Facelets support, without which we couldn’t be using Woodstock.
Popularity: 35% [?]

Thanks for writing so much detail in all these steps. I now have another one of your blogs to bookmark! (The other is your component writing checklist.) Good work!
February 26th, 2007 | #
Glad to see that you have time to write novella-length blog entries. I was afraid that maybe you were being overworked, but now I see there is plenty in reserve…
February 27th, 2007 | #
I see that Woodstack depends on DynaFaces library, I think because the AJAX support is built upon it.
That’s nice, but I am not sure if DynaFaces and Ajax4JSF can live together. In my application I am using Ajax4JSF, so I am not sure, now, if I can use the Woodstock components painless in the future.
Have anyone tried this combination?
February 27th, 2007 | #
If com.sun.faces.verifyObjects is enabled when deploying a woodstock application it throws a long list of ClassCastExceptions regarding ValueBindingSortCriteria, ValueBindingFilterCriteria, ValueExpresionFilterCriteria, VaulueExpressionSortCriteria. I’am new to JSF and faclets so I’m not to sure if this is a bug in Facelets, JSF, or the Woodstock components.
Might be best to disable the VerifyObjects Option while developing Faclets pages with woodstock support, as i cannot find the source of the problem.
March 6th, 2007 | #
Kenneth, thanks for that note. I’ve actually just run into that issue myself. I’ll turn off the option and see if that helps.
March 12th, 2007 | #
Your post helped a lot. Some experiences with Woodstock and Facelets we made:
http://blog.rainer.eschen.name/2007/04/01/when-theres-bad-smell-in-your-jsf-tag-soup-due-to-facelets/
April 1st, 2007 | #
I have the same question with al80. The reason I look at Woodstock is that RichFaces doesn’t have a file upload component and its data table is unsortable.
April 2nd, 2007 | #
hi,
very interesting article,
please i have a lot of problem to configure woodstock with facelets (conflits with jsf1.2)
i use netbeans that integrate facelets can you advice me how to do it.(integration witch jar use)
would you submit me your project.
thanks at all.
April 4th, 2007 | #
Although, we got the table stuff working we got tweaks with the tree. Our tests showed that Facelets create these. We’ll definitely skip Facelets (after tweaks with Trinidad, Tomahawk and Woodstock :sad::sad::sad:) and will have a look at jsftemplating. Cool that you help to get the “easier syntax” from Facelets into jsftemplating
April 13th, 2007 | #
reda,
I don’t use NetBeans, so I’m not sure what to tell you on that. What, exactly, do you mean by “conflicts with jsf1.2″?
April 27th, 2007 | #
al80 and Thai,
I have not tried using a4j with the WS components. If I get some time, I’ll try to see if I can make them live together.
April 27th, 2007 | #
Rainer,
Too bad you’re skipping Facelets. It’s pretty nice, but it *will* be nice to see it supported in JSFTemplating, though for some of those component libs, you may still see the same type of problems in terms of ViewHandler support. Woodstock works flawlessly under JSFTemplating out of the box, though.
April 27th, 2007 | #
I have been having problems rendering woodstock compoenents on the browser because the page is rendered as XHTML, as the facelets specification requires. Dojo uses functions to write to the XHTML DOM that are not supported under firefox (maybe IE also, i have not tested). Because of this incompatability the woodstock calendar components, and the Jump down feature on the Drop down boxes does not work. Does anyone else seem to have that problem?
I had this problem a few months ago and hadn’t looked at it since.
May 2nd, 2007 | #
Got the same problem that Kenneth Miles describes above: The drop down boxes just won’t work with XHTML in Mozilla. It seems to work just fine in Internet Explorer… — And yes: it drives me absolutely crazy.
You can get the calendar to work if you use Woodstock 4.0-200702221013 (got it from Ken Paulsen). Dunno if you can download a similar version from the Woodstock page.
Nice article btw.
June 25th, 2007 | #