TurboManage

David Chandler's Journal of Java Web and Mobile Development

  • David M. Chandler


    Web app developer since 1994 and Google Cloud Platform Instructor now residing in Colorado. Besides tech, I enjoy landscape photography and share my work at ColoradoPhoto.gallery.

  • Subscribe

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 224 other subscribers

  • Sleepless Nights…

    September 2006
    S M T W T F S
     12
    3456789
    10111213141516
    17181920212223
    24252627282930

  • Blog Stats

    • 1,040,365 hits

Archive for September, 2006

Using Tomahawk Tree2 Component in a Portal

Posted by David Chandler on September 25, 2006

To run Tree2 with client-side expansion, you need JavaScript in the page <HEAD>. Normally, this gets added by the Tomahawk ExtensionsFilter. This doesn’t work in a portal, however, because servlet filters don’t run in a portal. There are some patches in MYFACES-434 (portlet filter) you may be able to use, but here’s an easier workaround. I’ve used this successfully with Tomahawk 1.1.3 in both Jetspeed2 and Liferay.

First, use Tree2 with server-side expansion so as not to require JavaScript. The ExtensionsFilter is therefore needed only to serve up the image resources needed by Tree2, and image requests are handled through the Faces Servlet, not the portal, so the ExtensionsFilter will run as normal for these requests. However, Tomahawk 1.1.3 checks to see if the ExtensionsFilter has been configured, which fails in the portal context. Fortunately, you can disable the check with a web.xml context param.

So to summarize, you can use Tree2 1.1.3 in a portal without any of the MYFACES-434 patches if

  1. You use server-side toggle
  2. You configure ExtensionsFilter as normal for the Faces Servlet
  3. You disable the ExtensionsFilter configuration check as follows in web.xml:
    <context-param> 
         <param-name>org.apache.myfaces.CHECK_EXTENSIONS_FILTER</param-name> 
         <param-value>false</param-value> 
     </context-param>

/dmc

Advertisement

Posted in JavaServer Faces | Leave a Comment »

JSF Trick: Invoking an Action Method on an Item in a Datatable

Posted by David Chandler on September 8, 2006

Suppose you want to create a table of items and enable one or more action links for each item; for example, a list of files with a “check out” and “delete” link next to each. The usual approach is to create a java.faces.model.ListDataModel in your backing bean and call its getRowData() method from the action method in your backing bean to get the item for which the action was taken. These are great JSF features, but I recently found you can avoid even this code.

The trick is to put your action method in the class that represents the item. Then you can reference it directly in the view template, like this:

<h:dataTable value="#{fileMgr.items}" var="item">
    <h:column>
        <h:outputText value="#{item.name}" />
    </h:column>
    <h:column>
        <h:commandLink value="Check out"
            action="#{item.actionCheckOut}" />
    </h:column>
</h:dataTable>

In this example, fileMgr is the backing bean, and item is the datatable var representing a model object. The trick here is that JSF will go ahead and call the actionCheckOut() method on the item object, even though it’s in a model class, not a backing bean. This way, you don’t even have to mess with ListDataModel.

Neat as this is, it is usually only appropriate in the case of simple toggle actions that affect only the item properties. Most other actions (especially delete) are likely to need references to the entire collection of items or other classes such as DAOs which you would not want to reference directly in a class representing a domain object such as an item. Still, it will save a layer of code for simple actions and I’m tickled that it works.

Posted in JavaServer Faces | Leave a Comment »

 
%d bloggers like this: