Initially, I used a <h:commandLink/> with target="_blank". This worked well until the user entered criteria that failed validation. The new window was still created, and the validation messages were shown in the new window. This was not a good solution, so after some research and experimentation I came up a solution that meets the following criteria:

• Validation messages are shown in original window.
• A new window is not created when there are validation messages.
• A new window is not created when the entered criteria returns zero (0) results.

The Action Class

For this example, the action class is very simple:

public String getReportURL() {
    return "/pdfpopup/reports/reportDisplay.seam";
}

// Getters and setters omitted

public List<String> getReportData() {
    return reportData;
}

public void doSearch() {
    // This is where the work would actually happen
    reportData = new ArrayList<String>();
    for (int i = 0; i < selectOneValue; i++) {
         reportData.add("Report Row " + (i + 1));
    }
    if (reportData.isEmpty()) {
        facesMessages.add("Report will be empty, not popping up");
    }
}

I added the getReportURL() method to the action because there may be occasions where the report URL differs based on criteria. In the application I worked on, we had to support PDF and Excel reports, so the method returned the correct URL.

The action simply takes the criteria specified on the JSF page and populates a list of results based on that criteria. The PDF generation page will access the list later.

The JSF Page

The JSF page looks like this:

<ui:define name="body">
  <script type="text/javascript">
  //<![CDATA[
  function showReport(conversationId) {
  if (document.getElementById("messages") != null) {
    return;
  }
  var reportWin = window.open('#{reportAction.reportURL}' + '?cid=' + conversationId);
  if (!reportWin) {
    alert("Could not open the report window. Please disable popup blocking for this website and try again.");
  }
  }
  // ]]>
  </script>
  <h:form id="generateReport">
  <s:validateAll>
  <h:panelGrid width="100%" columns="1" style="text-align: center; font-weight:bold; font-size: 12px">
    <h:outputText value="Report Query"/>
  </h:panelGrid>
  <h:panelGrid columns="2" border="0" frame="none" style="padding-top:30px;">
    <h:outputLabel for="selectOneValue">Number of Output Rows</h:outputLabel>
    <h:selectOneMenu id="selectOneValue" value="#{reportAction.selectOneValue}" required="true">
      <f:selectItem itemLabel="Zero" itemValue="0"/>
      <f:selectItem itemLabel="One" itemValue="1"/>
      <f:selectItem itemLabel="Two" itemValue="2"/>
      <f:selectItem itemLabel="Three" itemValue="3"/>
      <f:selectItem itemLabel="Four" itemValue="4"/>
    </h:selectOneMenu>
    <h:outputLabel for="startDate">Report Period:</h:outputLabel>
    <h:panelGroup>
      <rich:calendar id="startDate" enableManualInput="true"
        value="#{reportAction.startDate}" showWeeksBar="false" datePattern="MM/dd/yyyy"
        immediate="true" required="true" label="Report Start Date"/>
      <h:outputLabel for="endDate">through</h:outputLabel>
      <rich:calendar id="endDate" enableManualInput="true"
        value="#{reportAction.endDate}" showWeeksBar="false" datePattern="MM/dd/yyyy"
        immediate="true" required="true" label="Report End Date"/>
    </h:panelGroup>
    <a4j:commandButton id="getReportLink" action="#{reportAction.doSearch}"
         value="Get Report" oncomplete="showReport('#{conversation.id}')"/>
  </h:panelGrid>
  </s:validateAll>
  </h:form>
</ui:define>

This is really the guts of the operation. When the commandButton is clicked, the doSearch() method will be executed. Once that call is complete, the oncomplete handler will be called.

The page template is configured so that any FacesMessages will be displayed in an element with id “messages“. If this element is present, we assume that either a validation error or no data message is being displayed and do not show the PDF. If the element is not present, everything is OK and we open the new window with the URL for the PDF. Note that it’s crucial to pass the conversation ID along so that the data loaded by the action will be visible to the page creating the PDF.

The PDF

For completeness, here’s the sample page I’m using to create a PDF:

<p:document xmlns:p="http://jboss.com/products/seam/pdf"
   xmlns:ui="http://java.sun.com/jsf/facelets"
   xmlns:f="http://java.sun.com/jsf/core"
   title="Sample PDF Report">
<f:facet name="header">
  <p:font size="12">
    <p:header borderWidthTop="0" borderWidthBottom="0.4" alignment="center">
      <p:paragraph indentationLeft="50">REPORT HEADER</p:paragraph>
    </p:header>
    <p:footer borderWidthTop="1" borderColorTop="black" borderWidthBottom="0" alignment="center">
      [<p:pageNumber/>]
    </p:footer>
  </p:font>
</f:facet>
<ui:repeat var="item" value="#{reportAction.reportData}">
  <p:font size="8">
    <p:table columns="1" headerRows="1" widthPercentage="100">
      <p:font style="bold">
        <p:cell verticalAlignment="bottom">Report Data</p:cell>
      </p:font>
      <p:cell>#{item}</p:cell>
    </p:table>
  </p:font>
</ui:repeat>
</p:document>

Full Sample Code

You can view and download the full sample code for this solution from here.

The standard procedure for this employer is to give candidates a simple phone screen before arranging an interview. Personally, I feel that having one person make a decision about whether or not I’ll “fit well with the team” after 10 minutes on the phone is ludicrous, but that’s the game I had to play.

During the phone call, I was asked several generic questions about Java. I gave what I felt was correct answers to the questions, but the interviewer wasn’t happy with my results. Every time I answered a question, I heard “Well, I was looking for…”, with the expected answer simply being a different wording of what I had said.

I chalked this up to the interviewer simply being used to different terminology than I for the same concepts, so I was a bit surprised when I wasn’t called in for an in-person interview. It wasn’t until a few days later that I realized that the answers I was expected to give told me quite a bit about the company, and that I wouldn’t have been happy working there had I been offered the job.

The particular question that stuck in my mind was a simple one. “What are some of the benefits of the introduction of generics in Java, especially in collections?”

I gave the answer that pretty much anybody familiar with Java generics would give: compile-time type checking, no need for casting objects, etc. What I got from the interviewer was “Well, I was looking for the fact that you don’t have to do instanceof checks all over any more.”

On the surface, this may seem like another way of saying what I said, but it’s actually quite different.

Before generics, you would need to cast objects to the proper class when retrieving them from a collection. This does not mean that you would be using instanceof to do this. The only situation I can think of that requires using instanceof with a collection is if there are a lot of heterogenous objects in the collection.

There are limited situations where storing different object types in the same collection makes sense. Most of the time, however, this is a sign of either lazy development or not understanding the collection mechanism very well.

It’s generally a good idea to only put one type of object into a collection. This makes it much easier to work with and avoids any need for instanceof checks. By “one type of object”, I don’t mean that all of the objects need to be the exact same class. Chances are good that all of the objects being placed into a collection have some relationship; perhaps they will all implement the same interface.

I may have completely misinterpreted the interviewer, but I have a very strong impression that he and perhaps others on his team are used to using collections as grab bags of widely different things. Personally, I wouldn’t want to maintain that code. I can hope that the addition of generics to Java has forced the interviewer to change at least one practice for the better. I’m glad I wasn’t called in for the job – who knows how many more “well, at least it works” practices are being followed? I’ve got enough of those at my current job; I don’t need to learn a new set.

Images:

Tin Can:

Java Code:

Reasons why it might be an issue:

• I use a Mac for most of development, and I hate having to drop into an emulator to work on Frame2
• I really would like Frame2 to run on the Mac, if just for completeness.

Reasons why it probably doesn’t matter:

• Who really runs Java webapps on Macs? Tomcat on Windows or Linux is OK, but it just feels dirty to me on the Mac.

Hopefully, there will be a version of Java 6 available for the Mac soon. At that point, I’ll probably make the necessary updates to make everything work. Until then, if you’re writing a web app and using a Mac – go with Rails.

Again, the Update Manager site is the preferred method for downloading the plugins, since it will gracefully handle version and dependency conflicts.

Update Site for Eclipse:
http://frame2.megatome.com/eclipse

Sourceforge Downloads:
Main Eclipse Plugin
Web Services Eclipse Plugin (requires at least version 1.3.3 of the regular plugin)

One other feature that the plugin is missing is a contextual editor for the Frame2 configuration file. It would nice to be able to get contextual help and hints when editing the config by hand, but I don’t think I have the time in the forseeable future to research how this works in Eclipse.

The plugin will be available for download from Sourceforge and I will be creating an update site here at frame2.megatome.com that will be the preferred way of getting the plugin.

Work on the Eclipse plugin continues, with a (hopeful) release date in the next week or two.

As an illustration, I was adding a feature to Frame2 today to allow some parameters to be passed between events within a mapping – without making developers use the HttpSession. After a couple of false starts, I had a pretty good idea of how to make the changes and starting ripping out code. I came up with several unit tests, and modifying code to make the tests pass. Pretty standard Test Driven Development…until I wrote the test that made sure event chain validation was working.

Before I explain the bug, I’ll give a high level description of how Frame2 works when submitting form data:

1. Form is filled out by user and submitted.
2. Frame2 looks up the appropriate event from the form action.
3. An instance of the appropriate event is created and populated by the introspector.
4. Based on the mapping for the event, Frame2 will then validate the event. This may involve the Commons Validator if it is enabled and/or overriding the Event.validate() method.
5. If validation fails, the mapping must specify a location for the framework to forward back to. This is usually the same page where the data was entered.
6. If validation passes, the framework then iterates through the list of event handlers, calling the handle() method. If handle() returns null, the framework continues to the next handler. A non-null result usually indicates an error, and the framework will forward to the location named by the result.
7. Once all of the handlers have been invoked, the framework will default to the view specified in the mapping. Usually this is just a JSP, but Frame2 supports forwarding to events – called “chaining”.
8. For the chained event, Frame2 is supposed to start back at step 2 and continue processing until it gets to the end of the chain.

Notice how I say “supposed to” in step 9? The framework was actually only going back to step 6, bypassing validation for all events except the first in the chain. Subtle, yes, and unlikely to be noticed by most users – but it’s still a bug. The bug has now been fixed so that the framework goes back to step 2 like it’s supposed to.

In case you’re wondering what use event chaining is, here’s an example:

1. User enters a blog entry and submits the form.
2. Frame2 validates the form data and begins invoking handlers.
3. The blog entry handler persists the data, perhaps to a database.
4. The default view for the event mapping tells the framework to forward to the “View All Blog Entries” event.
5. The framework creates the appropriate object and begins invoking the handlers in the “View All” mapping.
6. The “View All” handler populates all of the blog entries into the “View All” event.
7. The default view for the “View All” mapping is a JSP page, which renders the blog entries using JSTL.

Chaining allows the “View All” event to remain its own entity that can be invoked separately, while allowing the same functionality to be used in other places where appropriate.

By way of comparison, the feature I added allows the above sequence to be reworked like this:

1. User enters a blog entry and submits the form.
2. Frame2 validates the form data and begins invoking handlers.
3. The blog entry handler persists the data, perhaps to a database.
4. The blog entry handler sets an attribute with the new entry id into the context.
5. The default view for the event mapping tells the framework to forward to the “View Specific Blog Entry” event.
6. The framework creates the appropriate object and uses the context value(s) with the introspector to set some values in the event.
7. The framework then begins invoking the handlers in the “View Specific” mapping.
8. The “View Specific” handler looks up the entry with the specified id and sets its data into the event.
9. The default view for the “View Specific” mapping is a JSP page, which renders the blog entry using JSTL.

• Upgrade unit tests to JUnit 4. There are a lot of tests, especially the ones that mock a servlet container, that do a lot of repetitive work in setUp() . JUnit 4 has finally brought the ability to annotate methods to be run before and after all tests in the class with @BeforeClass and @AfterClass, respectively. Individual test setup activities can still be performed by annotating a method with @Before.
• Fix outstanding bugs. There’s only one right now, and it’s SOAP specific, so I may or may not fix it. It may take me longer to figure out how to reproduce the problem with unit tests than it’s worth.
• Add outstanding feature requests. Again, there’s only one, but it’s (in my opinion) a biggie – the ability to add parameters to the response when handling an event.
• Doc updates. The web services doc needs to be written, and I’m sure all of the other doc needs a good examination.

I’ll be testing the latest build with a web application that I’ve been working on for years that I’ve come to think of as an unofficial reference implementation of Frame2. I haven’t decided yet if the web app should become part of the project on Sourceforge or not. We’ll see.

Once the testing is done and I’ve released a new version of Frame2, I plan on working on the Eclipse plugin. The poor plugin has pretty much been ignored for several years now, and it needs some attention.

Naturally, this has led to unit test failures. Almost all of the failures have been easy to fix, but once in a while one pops up that makes me scratch my head. Here’s an example:

public void testGetIfEmpty() {
    assertTrue(this.errors.isEmpty());
    assertNull(this.errors.get(FOO));
    assertEquals(0, this.errors.get().length);
    assertEquals(0, this.errors.get(FOO).length);
}

In this instance, errors is a class that aggregates individual Error objects. The get(String) method returns an array of Error objects that have the specified key, while get() retrieves all Errors. Pretty simple, right? After my changes, the test fails on the assertNull() statement, which isn’t surprising.

The failing statement read assertNull(this.errors.iterator(FOO)) before I removed the iterator() method, which tells us a bit about how the API was originally coded. The iterator(String) returned null if there were no matching entries. However, as the unit test clearly shows, get(String) returns an empty array when it doesn’t find any matching Errors. Quite the difference, and potentially confusing – the developer has to remember which method may return null.

The API has now been changed to return an empty collection instead of null when no matching errors are found. Now, a user of the API simply has to call the method and loop over the result (zero times if it’s empty) without having to make null checks.

Whoever wrote this unit test obviously knew that one method returned null while the other returned an empty array for the same input, since the test passed. I only wish that person would have looked at those lines and noticed the inconsistency, instead of leaving it for me to find.

Then I went and RTFM.

FindBugs has a filtering system that makes @SuppressWarnings look amateur. Here’s an example: in the SoapRequestProcessor, FindBugs marked a warning that an Exception was being caught when no Exception was being thrown. After looking at the code and verifying that the try block in question throws several different exceptions, I created a filter entry. The entry looks like this:

<Match>
<Class name="org.megatome.frame2.front.SoapRequestProcessor"/>
<Method name="getEvents"/>
<Bug pattern="REC_CATCH_EXCEPTION"/>
</Match>

This tells FindBugs to match a specific bug type in a specified method in a desired class. This entry can be used in both an inclusion or exclusion filter – I use it to exclude that warning from the results.

Here’s a more complex example:

<Match>
<Class name="~.*introspector\.Bean\d+" />
<Bug pattern="EI_EXPOSE_REP,EI_EXPOSE_REP2"/>
</Match>

There are some test classes that don’t exactly follow good rules of programming when it comes to dealing with mutability. Since they are test classes, I don’t really care to fix them. Instead I set up the filter to match all classes in an introspector package named Bean1, Bean2, etc. Simple as can be!

If you aren’t using FindBugs, you should be. Go check it out.