Wednesday, March 12, 2008

Porting a Ruby on Rails Application to jboss seam

I did finally port my Ruby on Rails application to jboss seam.

The capsule summary is that it took longer than expected (not particularly unusual for software), looks better than it ever did but still needs some performance tuning.

Some specifics

image display
I went with the seam graphicImage tag (note xmlns:s=”
< 's:graphicImage' value="”#{artwork.thumb}” rendered=”#{not empty artwork.thumb}” < 's:transformImageSize' height="”50”" maintainratio="”true”">
< '/s:graphicImage'>

which I found to be slow -- much slower than doing a normal html < width="”x”/"> tag. (update -- this is due to the use of the 'transformImageSize' tag -- rdf 24 March 2008)

In the RoR code I conditionally chose one of two versions of the image tag
< %= if(@artwork.width_inches > @artwork.height_inches)
image_string = “< id =""> + “\” width=100/>”
image_string = “< id =""> + “\” height=100/>”

which rendered much faster.

The s:graphicImage tag doesn’t appear to be intended for rendering up to 20 images on a page -- my next revision will include the equivalent of the RoR code

data display
I was easily able to get data tables with nicely alternating row colors by adding the following to theme.css (I did it here, since the ‘alternating colors’ should vary with the theme)
.table-even { background-color: #ffffff; } .table-odd { background-color: #eeeeee; }

and then adding the following line to the *List.xhtml files
I did have some minor problems getting it to work since I had overwritten a class that applied to each cell and had given it a background color. I forgot that this cell class would take precedence, but was able to figure it all out with Firebug, an indispensable tool!

seam generator
The generator provided an invaluable starting point and some really nice features e.g., it creates tables with sortable columns for the list view. The table defaults to displaying the ID of nested objects, but it was trivial to change it to display something more appropriate while maintaining the expected sort behavior.

ajax suggestions
My goal was to consistently work within the framework. This occasionally put me at a level of abstraction above which I was comfortable (the operational metaphor being “trying to do X while wearing thick gloves”). This caused me to have a much more difficult time doing a drop down suggestion menu than expected e.g.,

< id="”roleDecoration”" template="”layout/edit.xhtml”">
< name="”label”">role
< value="”#{peopleHome.instance.roles}”">mmediate=”true">

since I was having a bit of a problem finding the exact ‘magic location’ for placing the “” tag relative to the tag, aka it all ‘just works’ if you have everything placed ‘just right

Being at a higher level of abstraction also forced some patterns that I found difficult to work around. For example, in this trail system an Artwork object has a framed? attribute backed by a boolean. The behavior that I wanted in the listing ‘query by example’ code was to either
to return framed artworks if the framed? checkbox was checked
to return all artworks if the framed? checkbox is not checked.
However, I could neither come up with a way to have elements on the restriction list take multiple parameters nor to return different restriction lists depending upon the query

my notes at that point say:
if you do this
List restrictionList;
if ((this.artwork != null)
&& (this.artwork.getShipable() != null)
&& this.artwork.getShipable().booleanValue()) {

restrictionList = Arrays.asList(SHIPABLE_RESTRICTIONS);
else {
restrictionList = Arrays.asList(RESTRICTIONS); }

You break the transaction model

I was able to fix this by adding this line to the RESTRICTIONS
artwork.framed in (true, #{ artworkList.artwork.framed})
which obviously will not generalize beyond the boolean case.


I found that the Hibernate documentation was very useful (when I took the time to read it in detail aka RTFM)
The expression language used is described reasonably well here

When I moved to a new version of richfaces to get suggestion boxes working it broke other minor portions of the page layouts. Although not a big deal, I found it disconcerting. Building this rich functionality in the browser is cool and all, but it feels fragile and is causing me to think about trying out flex (or air, its latest incarnation)

unit testing
I used HTMLUnit since it tests the complete end-to-end interaction.
Although I appreciate the ability to do faster, more thorough testing via mocks, I found that they gave me yet another thing to configure and wouldn’t give me the full end-to-end functionality that I was looking for.

I think that jboss/seam will likely prove useful. I have one other application that I’m building as a precursor to the extensible discovery system My biggest area of concern is the ability to do a good UI in this space which might prompt me to investigate the air/flex framework(s) at some point in the near future.

No comments: