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:

The single largest variable on any development team is the developers. I’ve found that moving to an Agile process like Scrum can really expose developers who’ve been hiding behind “traditional” processes.

Therein lies one of the biggest problems I’ve run into. One of my developers is not what you could by any means call a self starter. He has been able to get along well with the official process, which does not do a good job of tracking what developers are working on. Now that he’s been thrown into Scrum, it’s become quite obvious that he really doesn’t do anything until somebody nags him long enough to get him going.

This is where inertia comes in. This developer is a textbook example of an object staying at rest until the team lead can poke and prod enough to finally get him moving. His previous lead had simply taken it as granted that he would have to spend a certain amount of time micromanaging to get any work out of the developer. I think it’s a waste of time and energy for me to constantly remind him to pick a task and work it, but that’s what I’ve been reduced to doing. This week, for example, it took two days of nagging to get him to perform a ten minute refactor. (I would have done the refactor myself, but I have to trust that my team can do their jobs, too.)

I don’t know how to engage this guy. I can spend time collecting data and create metrics, but I don’t think that’s an effective motivator. What I’d really like to see is a commitment to the team and to the project that leads into a desire to pull his fair share. I don’t even know if these are feelings I can engender in this developer.

Motivation is an issue for teams using any kind of development process. Every team member reacts differently to various inputs. Some members like recognition, while others prefer a bonus. Some just want to be left alone so they can do the bare minimum to get by. I’m hoping this isn’t the eventual outcome with this developer.

(Click to get the shirt)

I’ve been coding with an agile mindset for quite some time now. Some practices have become second nature to me over the years. One of these practices is aggressive code refactoring, coupled with test driven development (TDD).

I’ve been adding new functionality to our system at my new job, and as usual I’ve been following my standard techniques. My part of the system involves handling certain requests and responses. I wrote unit and functional tests for the request half of the equation, then began to tackle the response side. As I added (and tested) functionality, I began to notice a large amount of similarity in the code. This in turn led me to create an abstract base class for both request and response, pulling up all of the shared functionality. This resulted in the actual request and response classes being quite small, with just a few method implementations from the base class.

So far, this activity should seem pretty normal to most developers. As I said, it’s pretty much second nature for me, and I don’t even remember consciously making the decision to make the abstract class. Imagine my surprise when my team lead admonished me for creating and abstract class, and warned me not to do it again without explicit approval.

Of course I had to ask why we would not refactor code in this manner when the opportunity presented itself. My lead’s answer involved several parts, none of which have convinced me that refactoring is bad:

1. The abstract class is not consistent with the rest of the system. This, to me, seems to be a fault of the system. I’m not knocking consistency, but at some point you have to realize that you may be building something that’s consistently bloated/overcomplicated/etc.
2. The abstract class changes the design. Huh? Sure, if I go generate a UML diagram of the system, there’s going to be this abstract class and inheritance there. This is the only place the design is different. Requests and responses are being correctly handled just like the legacy ones in the system.
3. Too much refactoring is bad, and each case should be thoroughly examined before code is changed. This is how religious wars start. My lead claims that developers start out on the “no refactoring” end of the spectrum, simply because they don’t know any better. Once they learn about refactoring, they then swing to the “refactor everything” end of the spectrum where anything and everything is a potential target. Seasoned, knowledgeable developers fall somewhere in the middle. I got the impression from this speech that my lead considers me to be on the radical end of the spectrum.

Why are people like my lead so scared of refactoring? The arguments given really seem more like rationalizations than actual reasons – they don’t really stand up to scrutiny. I have a hard time believing, for example, that my lead truly thinks that the system is better because each request and response is a totally separate class, albeit with most of the code copied and pasted from one to the other. If anything, he should know that this approach leads to more problems, no matter how pretty it keeps the class diagrams.

Co-Worker (who does not believe in unit tests): Okay. I just checked my changes in.

Me: There’s a bug in your code.

Co-Worker: How do you know? I just checked it in!

Me: It broke my unit tests. It looks like you’re not setting the flibbergibbet value correctly.

Co-Worker: What? How can you tell?

Me: JUnit showed me the difference.

Co-Worker: Oh. I guess I’ll fix it now. I would have found it eventually…

For what it’s worth, we’re handling Electronic Data Interchange documents – things that look like a page or so of line noise at a time. The bug was that one character wasn’t getting written to the output. My co-worker tests his code with the toString() and visual grep method. I’m not sure he would have ever caught the bug on his own. I keep trying to explain that unit tests are a Good Thing…