Pencils Down

The icefaces Resource button for download is a convoluted hack. Every time icefaces decides to paint the screen your resource must be completely available and rendered. This is extremely painful for messy stuff like generated PDF’s and the like.

I just switched over our code to use links to a servlet. On the jspx we have:

<ice:commandbutton
  partialSubmit="true" id="printButton" disabled="#{bean.printDisabled}"
  immediate="true"
  action="#{bean.print}"
  value="Print...">


This lets you “correctly” gray out the Print button where there is nothing to print. With the resource it is either present or not – kind of ugly UI design.

When the user clicks on the Print button I store whatever POJO I may need into a singleton storage mechanism. Something like a HashMap where the key is the time in mills since 1970. For our user base this is granular enough. You may need something stronger. Then we call the servlet:


JavascriptContext.addJavascriptCall(
  FacesContext.getCurrentInstance(),
  "window.open('viewFile?file="+ id +"', " +
  "'myWindow', " +
  "'width=600," +
  "height=300," +
  "directories=0," +
  "location=0, " +
  "menubar=0, " +
  "resizable=0, " +
  "scrollbars=1, " +
  "status=0, " +
  "toolbar=0');");


This just opens a popup serving up the ‘file’ requested. The servlet is in the same ear/war file so it can see the print store and uses the file id passed to retrieve the POJO data out of the print store. I was thinking it might be cool to post XML to the servlet, but this seems easier to do.

This is one of those errors that shouldn’t happen.  However, due to lazy-loading Hibernate is smart enough to realize you have loaded an object once before during a session and does not attempt to do so again – even though you have deleted it during the session and it should not be a part of any collection anymore.

A workaround I have started to use is to set the version of objects I am deleting to -1 and the later in time when I am about to persist or merge an object I check to see if the version is still valid first.  This includes objects I delete by hand and objects that may be about to be cascade deleted that I may later on attempt to persist/merge.

I am sure there is a smarter way to do this, but this works well.

One thing I was toying with was the error message that comes up for this exception usually mentions the object using the standard notation of <object>@<hashcode> where the hashcode that prints out is null.  This is a little wierd as the hashcode that I have in my entities is a int not an Integer, so I can’t tell how to poke at a null int to get the same effect as my invalid version/deleted flag.