Raible Designs

ActionForms: Struts' bastard child

Folks that rag on Struts seem to point to ActionForms as one of its major design flaws. I've been slightly frustrated with ActionForms this week, but overall, I think they're a good thing. It's possible my ActionForm affection is misguided. The major reasons I like them is because I believe they allow me to do stuff that is not possible in other web frameworks. I definitely could be wrong though, so I'm hoping the other framework authors/users will speak up and say "My framework does that!" Specifically, I'm talking to the WebWork, Tapestry, JSF and Spring folks.

I do wish that I could throw my POJOs up to my UI, so I hope the following things are possible with the WTJS frameworks. It would simplify things if I didn't need to transform POJOs -> ActionForms (particularly with Hibernate).

• Validation and re-displaying the user's entered values. I love Struts' Validator. It's great how I can generate the validation.xml file with XDoclet and have a "required" struts.validator tag right next to a hibernate not-null="true" tag. Two questions:
  
  1. Can any of the WTJS frameworks re-display the user's entered values? Specifically, back into the input fields where the user entered them? I think this is important for useability.
  
  2. Do any of them have the ability to generate client and server-side validation, or at least declaratively write it in XML?
  
  I'd love to find a way to hack the Validator to allow you to define validation rules for a POJO and then use an Interceptor to validate it. I don't like how Spring requires you to write YAJC (Yet Another Java Class) to do validation.
• Handling checkboxes. The basic reason for the reset() method in ActionForms is to handle checkboxes. Since unchecked checkboxes don't send a value - there needs to be a way to set a boolean back to null. I'm sure all of the WTJS frameworks support checkbox handling, I just want to make sure - and frankly - I'd like to learn a little more about how each framework handles it.

I guess there's only two reasons I like ActionForms - the major one being the ability to specify (and generate) my client and server-side validation in XML. If I don't find this same slick feature in the other frameworks, I might have to do a bit of hacking to do the Interceptor with Validator thing - but hopefully I won't need to go there.

A few thoughts on AppFuse

I've been thinking about how to structure AppFuse for the upcoming Spring and iBatis enhancements. These enhancements shouldn't require any directory structure changes. However, I've received some suggestions to change the common, ejb and web directory structure to be a little more inline with the tiers. So it would become something more like database, business and web (or dao, service and web). After thinking about this for the last couple of days, it seems to make sense. I picked up the notion of common from Erik Hatcher's JavaDevWithAnt, which I borrowed heavily from when creating AppFuse. Erik used common because this represented classes that would be included in both the web tier and the EJB tier. But since I (currently) don't plan on every adding EJBs to AppFuse, does it make sense? Even if I did, I'd probably only use SessionBeans, and those could easily fit into the service layer. The nice thing about moving the business layer (currently in web/**/services) to it's own directory is that it will get it's own JAR (with hardly any modifications to build.xml) and can be used outside of the webapp.

The nice thing about isolating the web directory to web-only classes is I can use Ant to replace any Struts-specific classes with WebWork or Tapestry. To prevent AppFuse from being cluttered with too many options, it'll ship with Struts out-of-the-box. If users want WebWork for their framework, they can download a WebWork version of the web-tier and run an Ant target that will replace all the Struts stuff with WebWorks stuff. It seems like the cleanest way to do web framework switching.

Another thing that might happen to AppFuse, caused by my enthusiasm to try out everything, is that it will contain too much stuff for a basic web application. It currently has security and user management built in, which is what most webapps need. I recently added in OSCache and Clickstream. OSCache is not enabled, but most webapps can probably use it somewhere. Clickstream is a different story. For most of the webapps I've built, this is not needed at all. Most of the apps are no more than 20 screens, and it's unlikely the client will care where people go the most. Another option that deserves ripping out is the idea of Struts' submodules. I tend to rip this out as the first thing when starting a new project. File Upload is something I've used rarely, so I should probably lose that feature too.

There are also other technologies that I've thought of adding to AppFuse, namely Quartz and Lucene. However, I've only used Quartz on 1 of my last 5 projects and Lucene on 2 - so obviously these might be considered bloat for a basic webapp. I think the best thing would be to implement these in AppFuse, on my own, and then document how I did it on the wiki (for an example, see diagramming build.xml with Vizant). If folks need to use it they can add it on their own. Documentation is always good, and if I can just document how to add stuff, I can certainly reduce the bloat.

Whaddya think - is it better to include options out-of-the-box or simply document them? Should I restructure the directories to match the tiers more?

Mock Shmocks!

Let me start this post by saying that I've never used Mock Objects in my JUnit tests. Simon digs it, crazybob is an advocate and so is the gang that wrote Open Source Programming. In fact, the OSP book says that your unit tests should only take a couple of seconds to run! A couple of seconds!? Mine aren't that fast, which definitely makes me think I should look at Mocks to try to speed things up.

However, there is a method to my madness. Almost all my tests depend on a database connection and use DBUnit to populate the database before running. This can be time consuming, but it's not too bad for what I'm getting: real tests that verify the environment, not just the code. I just ran all tests in the application - 8 minutes 7 seconds - for 165 JUnit/Cactus tests and ~25 WebTest (JSP) tests.

If I did use Mocks, I wouldn't have discovered all the bugs in my code this week. When migrating from MySQL to DB2, I found that some things worked on MySQL, but they didn't on DB2. I modified the code, doing some tweaks to make Hibernate happy, and voila - now everything works on DB2 and MySQL. Furthermore, all my errors occurred when running my app in the container, and when I used simple JUnit tests (on my Managers) to test the same logic, it worked.

Who knows, I'm definitely learning new stuff everyday. Maybe it's possible that Mocks could do all this, but testing the production environment seems pretty important to me.

Coldtags - I dig the product and the support

I noticed from reading JavaLobby's Weekly News that Coldtags has a new version:

Coldbeans Software announced the major new release of Coldtags suite. This suite provides 160+ custom JSP tags for common programming tasks faced by JSP developers. And now this suite includes custom tags similar to web controls in .NET framework.

Find out more here: http://www.servletsuite.com/jsp.htm

I currently use the Country tag and the State tag and they're awesome (simple, but still something I needed). One feature I'd like to see is XHTML compliance for these tags, so I send them an e-mail.

Any chance of making this (and statetag) XHTML compliant? It would basically involve allow assigning an "id" attribute ("style" would be great too) and changing SELECTED to selected="selected".

Lo and behold, I got a quick reply less than an hour later:

Hello Matt,

it will be done.

Best regards,
Coldbeans support

P.S. I would like to note that the wish list for any component is open. So, feel free to suggest new features/options etc. you or your clients need and we will add them to upcoming release. Your suggestions for new components are more than welcome also.

Sweet! Note the P.S. - send your suggestions if you have any.

One Hour Later: Both tags have been updated with new attributes, and it's now XHTML-compliant. ;-D

Velocity's DataSourceResourceLoader

In the current project I'm on, one of the major requirements is to have the ability to send job postings to job boards such as Monster.com, CareerBuilder.com, etc. - as well as local newspapers. When I first started this project, I went about contacting all of these advertisers and explained that we'd like to automate the process of talking to their system. I found that many of them preferred a simple e-mail with the job posting, but others wanted us to FTP a pre-formatted document to them.

I figure the easiest way to handle this is to use Velocity. By using Velocity, and storing templates in the database, users of the system can either (1) use a default template or (2) customize a template for a specific advertiser. This was all easy enough since we're using Struts Resume as a baseline for this project, and Velocity is already built-in.

I remembered seeing that Velocity had some sort of database ResourceLoader, so I went searching and found the DataSourceResourceLoader:

This loader will load resources from a DataSource such as a database. This loader is not built as part of the standard build as it requires J2EE support. To build this loader, please download the J2EE distribution, move the j2ee.jar into the build/lib directory, and then build the new velocity jar with the jar-j2ee build target. For more information on this loader, please see the javadoc for DataSourceResourceLoader.

After checking out Velocity 1.4.1 RC1 (are they ever going to release this thing?) from CVS, I was able to build a new Velocity JAR. To compile using J2EE 1.4, you have to modify the VelocityServletTest, or delete it. I then replaced velocity-1.4-rc1.jar with this new JAR (which is actually 4KB smaller), configured velocity.properties and Voila - it worked! Clean and easy integration - just the way I like it.

[Review] J2EE Design and Development

I finished reading Rod Johnson's J2EE Design and Development today. 700 pages took me a little over 2 weeks to knock out. This book is definitely targeted at experienced J2EE developers, which is nice. I tried to do the same with my Struts chapter in Pro JSP and I wish books would do more of it. However, the problem with targeting a more experienced audience is you lose a lot of potential buyers. Rod is definitely one sharp fellow and it shows throughout this book. Either that, or he's just got a lot of experience working with the J2EE stack in his career.

The framework described in this book eventually became Spring - and it's really just a culmination of all the things that Rod has used on his previous projects. In that respect, it's similar to AppFuse, which I created to assist me with my Java webapp projects. Like Spring, AppFuse contains all my learnings and choices over the last couple of years. Just to be clear, I don't mean to imply that AppFuse is anything close to Spring as far as functionality - but I do believe they're similar in their goals. Spring is designed to make J2EE easier, while AppFuse is designed to make project setup and testing easier. Hopefully, when I start using some Spring features in AppFuse, developing with AppFuse will become even simpler.

Back to the book. I found the first few chapters somewhat boring since they covered a lot of the stuff I already knew about J2EE applications. The middle part of the book was on Spring's simplified JDBC approach and it also covered EJBs. I tend to shy away from writing JDBC these days, especially since Hibernate suits my needs so nicely. If I'm working with an existing database and there's a lot of SQL code already, I'll use iBatis. And EJBs, blech - I've never had a need for them. Admittedly, a lot of my projects are small and don't require container-managed transactions. I've also heard rumors of CMT being a part of Spring - so who knows if there's any good argument for EJBs anymore. Anyway, I found the middle part of the book quite boring as well since I don't much care about JDBC or EJB.

The last part of the book, however, peaked my interest. It discussed MVC design, View Technologies (i.e. JSP, Velocity, XSLT, XMLC, PDF) and basically a lot of stuff related to the web tier. In this area, I was most impressed with XMLC, which allows you to write HTML pages - then use Java to manipulate it's contents. Very slick stuff for having a static prototype that also serves as the code for your app. I don't see myself switching from JSP to XMLC, but I dig the option. In the Performance Testing and Tuning chapter - great examples where given and seemingly real-world optimizations where made. This chapter could prove to be a handy reference for enhancing performance with simple caching.

Overall, I thought this was a great book, although a bit heavy on the EJB stuff for me. Now I'm motivated to learn more about Spring. In the process, hopefully I'll figure out how it makes iBatis and Hibernate easier to work with (links are most welcome). Next up is Java Open Source Programming(500 pages), which I expect to take another two weeks to polish off.

Alternative web frameworks for AppFuse

I've was thinking about the AppFuse Roadmap for a bit today - and it hit me. The hardest part of supporting frameworks like WebWork and Tapestry is going to be replacing the Struts features I'm confortable with. For WebWork, it should be fairly easy to replace Tiles with SiteMesh, but for Tapestry - does a templating framework even exist? Other things that might be hard to implement in Tapestry are the DisplayTag (although Erik Hatcher did mention it's easy to implement in Tapestry) and Struts Menu. I imagine doing something like implementing a menu with CSS/JavaScript isn't too hard in Tapesty - but can it be configured from an XML file and a Velocity template? Implementing these components into WebWork should be easy since it supports JSP, but Tapesty is a whole different animal. I've also heard that JSF already has a grid component - and the struts-faces library should allow me to use Struts Menu easily with JSF.

I guess the good news in all of this is that I will discover if this stuff is possible or not - instead of just wondering. If you do happen to know the answers off the top of your head - please let me know. The real question is - after all of this - which framework will I choose as my favorite. Stick around and read about my journey into these other frameworks from the perspective of a hardcore Struts developer and enthusiast. I don't plan on trying to prove that Struts is better - I just want to find the beauty of these other frameworks and report if it's all hype or actually true.

AppFuse 1.3 Released!

This release fixes a few compatibility issues with Resin and other databases - specifically PostgreSQL and DB2. The major new functionality in this release is Easy Database Switching. Basically, you can very easily switch from using MySQL to PostgreSQL by only changing a few properties in your build.properties. I implemented this on my current project last week because I do most of my development (at the client) on a PowerBook. The client wants to deploy onto a DB2 database - and there is not DB2 install for the Mac. Since Hibernate allows you to easily switch between databases, I figured I could develop using MySQL on the Mac, but have the default (CVS version) use DB2. One of the things I didn't want to do was to have a build.properties.sample, because I love projects that "just work" when you type "ant". So I changed the the build process so that database.properties is generated from default settings (MySQL) or the settings in build.properties (if specified). As part of the build process, Ant looks for the following build.properties files:

• ${user.home}/.${ant.project.name}-build.properties
• ${user.home}/.build.properties
• build.properties

What this allows you to do is to take your customized database settings and put them in ~/.build.properties and they'll be applied to any AppFuse-derived project. This makes it easy to keep the CVS version of your project tied to one database and a developer's local version tied to a different database.

While it's true that you'll most likely only talk to one database during the duration of your project, this exercise proves that it's easy to migrate from MySQL to another database. It also proves that AppFuse can easily integrate with other database (at least as of this release). Slick stuff IMO.

• Download (~12.1 MB for src, ~4.3 MB for bin)
• Release Notes

One of the best parts about developing AppFuse is that it's not a library. As a developer, I don't really have to concern myself with backwards compatibility. This means that new functionality can be added quickly and easily and old stuff can be ripped out. It's too bad all OS "products" can be this easy.

What about AppFuse's future? Check out the AppFuse Roadmap to see what I'm thinking about.

DJUG Meeting: The Future is Swing

I attended the Denver JUG meeting tonight and definitely enjoyed myself. It helped that I got to see an old friend, but it was also a nice refresher on XSL-FO and a great overview on J2EE UI choices. The basic concepts meeting was on XSL-FO, which as far as I know, is mainly used for creating PDF documents from XML content. Apache's FOP is widely used for doing XSL-FO in Java.

So here's a question for you - if I want to produce PDF versions of my resume (in struts-resume), which technology should I use? I know it'd be fairly easy with XSL-FO, but what about JasperReports? I'd like an easy way for users to be able to upload new "templates" for the PDF version of their resume, so FO might be the way to go. In addition, I'd also like to implement the PDF-rendering technology that I'll likely use on a real-world project. Are there some good APIs to use?

I did some XSL-FO work a couple of years ago and it seemed pretty cool, but it required a lot of trial and error to get things looking right (as is the case with most XSL). My favorite tool at the time was RTF2FO, which allows you to create a Word document with the look you want, save it as an RTF, and then convert it to a FO (.fo) document. Pretty slick stuff - it looks like they have a free trial and it's only $50/machine. The project I used it on was only 3 weeks, so the trail version did me just fine.

The main presentation was delivered by David Curry, who seemed to be an expert on J2EE UI choices.

David Curry is Director of Systems Development for ADP/SIS, part of the ADP Brokerage Services Group. He and his team use J2EE with DHTML, XML and Swing to develop mission-critical desktop productivity applications for brokerage and bond trading firms.

The main thing that impressed me was that David has been developing the same application since 1992. The app started out as a PowerBuilder desktop app, and moved to an HTML app, then DHTML - and now they're moving to Swing. They recently chose Swing (with the help of JGoodies) over their DHTML interface because 1) Java Web Start makes it much easier to deploy and 2) it's much more responsive for users on dial-up connections. David mentioned that it's a good idea to break your app into many separate jars so users don't need to update the entire app for new releases (a.k.a. JNLP Versioning).

I've often argued that you can make a webapp do almost anything a desktop app can do, but I can't argue with the bandwidth thing. It does take a long time to download a webapp that has a lot of JavaScript, CSS and images that make it rich. David mentioned that Gartner expects HTML interfaces to subside in the coming years, and for rich UIs (like Swing and SWT) to become more the norm. In one sense, I hope they don't - the only reason I'm in this industry is because of my HTML/CSS/JavaScript skills. It's all I know. Sure, I could probably learn Swing, and I might even like it, but I'd rather not. Learning Spring, WebWork and Tapestry sounds like more fun. Of course, if they can support a Swing UI, then I've lost nothing by learning them. I know WebWork does, but what about Tapestry? Is it view-technology-agnostic?

On the other hand, Swing does have some advantages:

• There aren't as many choices. Desktop apps are desktop apps, they should look like them. A lot of webapp developers (including myself) can get caught up in making a webapp look like a great website. The web offers so many more choices for look-n-feel that it's hard to decide which is right. I spend more time tweaking UI code (JavaScript and CSS) than doing anything else.
• Java Developers can develop the UI. In my experience, I have a rare set of skills - a strong HTML/CSS/JavaScript background, and a firm grasp of Java. The industry rumor is that there's HTML developers and Java Developers, but they're rarely the same person. David mentioned that there team is nicely consolidated to 6 developers - and everyone knows how to program in all layers. This sounds like smart management to me, moreso than Swing makes your team more efficient.

The other side of the coin is that Swing will never replace many webapps. For instance, it could never replace Roller. Why would readers want to download a Java app to read this site. However, since most of you probably use client-side aggregators and client-side editors, maybe the shift to desktop apps has already started...

The Verge Web Framework

After reading this post on the Server Side, I'd hate to be the guy who invented Verge. He's getting pounded like a rabbit during mating season!

Personally, I don't think there's anything wrong with another web framework. Competition is good. The funny thing is that I've never had a need to migrate away from Struts. I do admit that the IoC (Inversion of Control) in WebWork looks cool, but I don't have a need. After reading most of Rod Johnson's J2EE Design and Development, I do understand IoC (I didn't have a clue before), but I still don't see how I need it. I've never run into a problem with Struts that I couldn't solve. Maybe it helps that I've written my own app to make Struts development simpler.

Even though I do like Struts, and I do find it easy to develop with, I also plan on stuffing my head in a couple of books and learning all about Spring, Tapestry and WebWork. Why? Mainly because I'm a fool and I can't be happy just sitting on the couch and watching TV (which would probably help my blood pressure and make my family happier). I'm a fool because I'd rather learn than relax. Back to the point - why do I want to learn these "big 3?" To be honest, it's primarily because some big names (and folks I'd consider friends) are saying they're cool and they'll make my job easier. If only I wasn't so easily influenced...

What I hate about all of this is that as soon as I decide to integrate Spring into AppFuse, it becomes more complicated. Yes, an XML BeanFactory file is more complicated than Interface i = new InterfaceImpl(), especially for newbies.

Furthermore, I'm willing to bet that I'll end up writing workarounds for issues I encounter in Tapestry and WebWork. I'll even put my money where my mouth is - if your framework doesn't require me to write any workarounds, I'll donate $100 to the project. Heck, if it really is that cool - I'll donate money regardless of workarounds.

The worst part is that there's really no reason to convert my Struts webapp to these newer, cooler frameworks. About the only good reason is so I can say "I know the XXX Framework." I doubt XXX Framework will make anything easier, but it certainly might make my webapp a whole lot cooler.