Vertical Scrolling in JSF Datatables

The vertical scrollbar on the ICEFaces ace:dataTable is flakey, though pagination works fine. This is apparently also true of PrimeFaces, and probably other JSF frameworks. To enable a scrollbar without pagination, a workaround is to set scrolling=false, and then wrap the datatable in a div:

    <div style="overflow:auto;width:100%;height:180px;">
        <ace:dataTable ...>
        </ace:dataTable>
    </div>

The simplest way to add tooltips to ICEFaces components:

As the first tag within the enclosing <h:form>, add
        <ace:tooltip id="tooltip" global="true" speechBubble="true"/>

For each component, add the attribute
        title="tooltip text"
Where, of course, "tooltip text" is the actual text you want displayed.


For <ace:menuItem> components, instead of title, use the attribute helpText.


The global attribute specifies that tooltips should be created for all elements that have a title or helpText attribute. The speechBubble attribute adds a directional indicator that seems useful to me. I assume this works similarly with other JSF libraries.


Styling for the tool tips is done via ui-tooltip. Example CSS:
        .ui-tooltip { font-size:12px; }


It looks like the RichFaces version may have more options, but more complexity. In fairness, I've
not dug deeply into RF, as I am implementing in IF.

Bang Important

When using a framework that in some cases does weirdly nested stuff that overrides your CSS (I'm looking at you, ICEFaces), the CSS directive !important can be your friend. But maybe it's the sort of friend you need to keep a close eye on.

This is something it took me days to find documentation for, and certainly could cause a maintenance headache, but it falls into the the good-to-know category.

Case in point: with an ICEFaces ace:dataTable, displaying multiple rows from a database query, the table would not display the full number of rows, even though it was sufficiently large to do so, because the <div> that contains all the rows, class name ui-datatable-scrollable-body, was getting its max-height set to 100px, no matter what I did. This was enough to show three of four rows. I was finally able to get it to work with this CSS entry:

.ui-datatable-scrollable-body { max-height:250px!important; }

I may have to do some further tweaking so as not to torch any other datatables I may use elsewhere in the application, but at least now I can move forward. And I'll keep glancing over my shoulder, making sure this helper doesn't try to stab me in the back.

Nobody is singing the Aria.

The lack of clear and readily available documentation for support of Section 508, WAI-ARIA, and other accessibility standards in the various JSF libraries, such as ICEfaces and PrimeFaces, is shocking, and really pretty shameful.

Given that the support of user with various disabilities is not only the morally and ethically right thing to do, but in many cases is actually required by law in the US and most other countries, it points to a lack of interest by those privileged to not have to deal with those disabilities.

I suppose that means me, too.

Viewing fake composites, or compositing fake views

Using Hibernate to retrieve data from a database view that contains a join can be tricky, as Hibernate expects there to be a unique primary key. The trick is to fake a composite key using the @Embeddable annotation in a PK model class that contains the properties/@Column references chosen for the composite key, and a the @EmbeddedId annotation in the main model class to include the PK class as the id property.

There's lots of documentation in cyberspace on the syntax for that, but there's one piece that almost all of them miss, and that is how you actually reference the properties that are defined in the @Embeddable compound key class.

First, do not duplicate the properties in both models; they should only occur in the PK model. The PK class is defined as a property of the main model class, so the reference is model.id.property for each element of the CK, instead of model.property.

I created accessors in the main model for the key properties that test that there is an instance of the PK model defined, primarily for testing. Example:

    public String getFirstName() {
        if ( null == this.id ) {
            return null;
        }
        return this.id.getFirstName();
    }

    public void setFirstName(String firstName) {
        if ( null == this.id ) {
            this.id = new ErmsDocOrgPrsnDetailPK();
        }
        this.id.setFirstName( firstName );
    }

It remains to be seen whether those will actually be needed.

Apache Tomcat JNDI mapping

Suppose that an intrepid Java developer is writing a web application that runs in Apache Tomcat, and that connects to a DBMS using a JNDI (Java Naming and Directory Interface) specification. And suppose that, instead of the usual Tomcat location for the JNDI entry—conf/context.xml—her manager has told her to put all application specific Tomcat configuration in conf/server.xml instead. How then does she make those JNDI entries visible to the app, without modifying any other Tomcat configuration files?

She does it by creating or editing META-INF/context.xml in the web app, with a <ResourceLink> whose name matches the JNDI <Resource> in the server.xml file.

Examples

Apache Tomcat conf/server.xml:

---

...
   <GlobalNamingResources>
    <Resource   name="jdbc/oraDataSource"
                description="Oracle JNDI Datasource"
                auth="Container"
                type="javax.sql.DataSource"
                driverClassName="oracle.jdbc.OracleDriver"
                url="jdbc:oracle:thin:@AMEDMRMCA4397.amed.ds.army.mil:1521:MRMCD"
                username="user"
                password="pass" />

    <Environment name="Common.Web.APPNAME" type="java.lang.String" value="WebAppName" />   
  </GlobalNamingResources>
...


---

Web app META-INF/context.xml:

---

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project>
<Context>
    <ResourceLink name="jdbc/oraDataSource" type="javax.sql.DataSource" global="jdbc/oraDataSource" />
    <ResourceLink name="Common.Web.APPNAME" type="java.lang.String" global="Common.Web.APPNAME" />
</Context> 

---

Without that magic mapping piece, she will probably get an error about 'no suitable driver' at the first attempt to open as a database session, and that may be frustrating to debug, and make her sad.