Raible Designs

Struts tip o' the day ~ using bean:size

A co-worker turned me on to this one today - you can use <bean-el:size collection="${myForm.list}" id="listSize"/> to get the size of a collection and expose it as a pageContext variable. I've been looking for this sucker for years! Usually, I end up putting a getListSize() getter on my form to accomplish this, since none of the other tags (including JSTL) allow you to get the size of a collection.

Pro JSP has arrived!

I received my complimentary four copies of Pro JSP tonight - whooo hooo! It sure is cool having your name on the cover of a book. ;-)

Congrats to all the other authors that feel the same way.

Thought of the day ~ WebWork

"At least when I do decide to sit down and learn WebWork 2, I won't have to learn WebWork 1."

I will learn it (someday), and I expect it to only take a day or two, but I'm going to wait for someone else to figure out how to do everything, and then I'll read about it and search the mailing lists. I feel like I've learned every little nuance of Struts (and many other OS packages) - I'd rather someone else swim in these bleeding-edge waters first. Hope I can stay dis-interested for a while longer... ;-)

Tiles Tips o' the Day

Here's a couple of things I learned today that might be useful to you Struts developers out there. When using Tiles, you'll normally import all the attributes into your baseLayout.jsp, and then your attributes are exposes as beans/scripting variables (you can actually grab them with JSTL tags). Rather than using:

<tiles:importAttribute/>

Use:

<tiles:importAttribute scope="request"/>

And then all your inserted pages can access these attributes. Pretty slick when you got a little JSTL love in the mix. The second tip is how to implement definition path switching. Let's look at the following baseLayout definition as an example:

  <definition name=".baseLayout" path="/layouts/baseLayout.jsp">
    <put name="titleKey"/>
    <put name="header" value="/common/header.jsp"/>
    <put name="sidebar" value=".sidebar"/>
    <put name="footer" value="/common/footer.jsp"/>
  </definition>

You currently cannot change the "path" attribute with a Controller, so you have to do it as the Tiles author recommends - by changing your path to refer to an action. So I changed the path on this particular definition to be:

<definition name=".baseLayout" path="/do/switchLayout">

Where my action-mapping is defined as follows:

 <action path="/switchLayout" 
   type="org.appfuse.webapp.action.SwitchLayoutAction">
   <forward name="printLayout" path="/layouts/printLayout.jsp" />
   <forward name="baseLayout" path="/layouts/baseLayout.jsp" />
 </action>

Then in SwitchLayoutAction.java, I have the following code:

boolean print =
    Boolean.valueOf(request.getParameter("print")).booleanValue();

// see if a print parameter is passed in the request
if (print) {
    log.debug("switching base layout to printing...");

    return mapping.findForward("printLayout");
} else {
    return mapping.findForward("baseLayout");
}

Pretty slick IMO! It's easy to make the printLayout.jsp only contain some simple wrapper stuff and only do <tile:insert attribute="content"/>. Of course, in this particular example, you could just use a print stylesheet (media="print"), but that doesn't work so well on 4.x browsers (man I hate those beotches).

Refactoring Struts Menu

I made a bunch of changes to Struts Menu (a.k.a. Navigator) for use in my current project. Highlights include dynamic parameters (configured in menu-config.xml) and the ability to create menu templates using Velocity. The full story can be see on my wiki.

And yes, I did really post this at 2:30 in the morning - ugh, I'm off to bed!

In August of Last Year

I began to learn a whole lot about Ant from Erik Hatcher. Good guy, great words - fun stuff.

Vanity URLs in Struts

I figured out a way to make your Struts' app have URLs like the following:

http://raibledesigns.com/weblog?method=edit
http://raibledesigns.com/weblog.jsp?method=edit
http://raibledesigns.com/weblog.html?method=edit
http://raibledesigns.com/weblog.php?method=edit
http://raibledesigns.com/weblog.asp?method=edit

Might be a nifty little trick to try. Pump out a version of Roller with this feature enabled and you could say you made a .NET version! ;-)

Here's how:

1.  I created a RequestFilter that maps to /*
2.  This filter checks to see if request.getServletPath() matches any of the
action paths in struts-config.xml.  If so, it forwards to the action.
3.  As an added feature, I added a set of allowed extensions to this
filter's init parameters.  So far I have .jsp,.html,.asp,.cfm (using .jsp
ensures no one links to them directly, MVC enforced!) - so marketing can
choose what technology they want to convey ;-)

This seems to work great.  For example, I have an "advancedSearch" action
defined as follows:

    <action path="/advancedSearch"
      type="org.apache.struts.actions.ForwardAction" 
      parameter=".advancedSearch"/>

(ForwardAction will eventually be replaced, if necessary, with a real
action).  This allows all of the following URLs to work:

http://site.com/do/advancedSearch (works with Struts by default)
http://site.com/advancedSearch
http://site.com/advancedSearch.html + all other extensions listed.

More information (including source code) can be found on the struts-user mailing list.

JSF: Allows WebWork style Actions

Am I working too late or does JSF allow a WebWork style Action? According to this post, you can have your properties and your logic in the same class (like WebWork). Also, no more worrying about BeanUtils.copyProperties()?

Struts encourages you to use Strings for field values that might need conversion, in order to redisplay correctly in case of conversion errors. You don't need to worry about that with JavaServer Faces, because the redisplay is handled by the components themselves. You will generally use the native data types for your field properties.

Regardless of what the WW Developers say, I think I'm gonna dig Java Server Faces.

SSL switching with web.xml

Craig McClanahan explains how to force SSL using settings in your web.xml. Pretty cool stuff, I guess I didn't realize that you could have a <security-constraint> without having an <auth-constraint>. This sure seems a lot more straight forward than using SSLExt or a custom tag library.

Persistence Options with existing SQL

At my new gig, it's not an option to use Hibernate. Their data model is too complex, and they've already written a bunch of code and it's corresponding SQL to get the information they need (think lots of inner joins, stored procedures and selects in where clauses). It was my task last week to port all the JDBC from one project to a more general framework to be used by all the websites we're building. The existing code is in the following form:

PreparedStatement pstmt = 
    conn.prepareStatement("select * from table where id=?");
pstmt.setInt(1, id);
ResultSet rs = pstmt.executeQuery();
MyBean bean = new MyBean();
if (rs.next) {
    bean.set(...);
    ...
    bean.set(...);
}

After doing all my persistence with Hibernate for the last year, it made me cringe to have to resort to this archaic (though tried and true) way of populating my objects. So I pinged the struts-user mailing list and asked what my options where for populating an object from a ResultSet. Basically, I was looking for a 1-2 line solution that didn't affect performance too much. After jossling back and forth for a while, I came up with 2 options:

• Use a ResultSetUtils utility class, such as the one from Ted Husted.
• Use iBATIS.

I did some performance testing and the ResultSetUtils class had the same performance numbers as rs.next() { set, set, set }, so it was definitely a viable solution. The downside? You have to name your resultset columns the same as your object's properties - and it's case sensitive. iBATIS was also a slick solution - as soon as I added <settings useBeansMetaClasses="false"/> to my sql-map-config.xml file, the performance was comparable to the ResultSet options (I turn it on when deploying, off for unit tests).

My Point: We're using iBATIS for our Persistence framework, and I dig it. It allows us to keep the complex SQL (externalized in XML files) that has already been written and it took me about a 1/2 hour to setup. I'd recommend Hibernate if you're starting a DB from scratch, but iBATIS seems to be a great solution when the SQL is already in place.

Will I add an iBATIS option to any of projects? Naahhh, then I'd have to work with Hibernate to export the SQL for each call, and I'd have to update my XML file's SQL everytime I change something in the DDL (currenly Hibernate and XDoclet perform this magic).