Raible Designs

My JSF Experience

Of all the MVC Frameworks I've developed with in the last few weeks (Struts, Spring MVC, WebWork and Tapestry) - JSF was by far the worst. And it's not the implementations that are the problem, it's the spec itself (as far as I can tell). Plain and simple, it does not simplify web development.

I spent 3 days developing a simple JSF app - most of it which I had done in the first day. The last 2 days have been spent migrating to MyFaces and trying to find clean ways to do things. My perspective on JSF after this experience? Run away. Run far, far away. All of the above mentioned frameworks are MUCH superior to this technology. Let's get on with the things I learned.

• MyFaces handles duplicate posts nicely. If you hit "reload" on your browser after saving a record, you get presented with an empty form rather than a duplicate record. I believe I got a duplicate record with Sun's RI.
• The ability to specify an "action" attribute on a button (or a link) and them map that action to a page (in faces-config.xml) is pretty cool.
• Every button or link clicked results in a form post. That's just wrong - why can't I have true links like the web is supposed to? So much for bookmarks.
• Saving state on the client results in enormously long URLs and/or hidden fields.
• JSF support is fairly non-existent. Unlike the other MVC frameworks, the MyFaces mailing list has hardly any traffic and the Sun forums aren't much better.
• The MyFaces website seems to be down whenever I want to look something up on it, like right now.
• I did find some CRUD examples, like this this one, but was disappointed to find that i18n is not considered for setting success messages. I ended up using the solution described in this post. 6 lines of code to set a success message - you've got to be kidding me! Most frameworks have a simple 1-2 liner.
• Waiting for JSPs to compile the first time has surprisingly become painful after using Tapestry, Velocity and FreeMarker for the last 2 weeks.
• Integration with Spring is fairly easy (code is in CVS), but MyFaces spits out an error when it shouldn't be.
• Validation messages are ugly. For instance, when a required field isn't filled in, I get: "lastName": Value is required. I was able to override the default messages, but I was never able to use the label of the field (vs. the field's id).
• The <h:messages> tag is practically worthless. Sure it's great for displaying messages (error and success), but that's about it. It has a "layout" attribute that doesn't even work in Sun's RI, and in MyFaces it just wraps a <span> with a <ul><li> or a <table>. Both of these layouts are useless b/c you can't set a css class on them. I ended up using "table" and having to set a generic CSS rule (width: 100%) in order to get the message/error bar to show across the top of my page. This tag also doesn't allow you to escape HTML.
• The <h:dataTable> component is nothing like the displaytag. MyFaces claims to have a pageable/sortable component, but it requires custom logic/methods in your managed-bean. Yuck. I ended up using <h:dataTable>, which has neither sorting or paging. This is only because I couldn't get an <h:commandLink> working inside a displaytag column.
• JSF-created apps are pretty much untestable. Managed-beans are testable, but the UI seems really difficult with jWebUnit and Canoo's WebTest. IMO, it should be possible to specify a URL to edit a record (i.e. editUser.html?id=2). With JSF and my master/detail app, the link to edit actually sets about 5 hidden form fields with JavaScript and then submits the form. I could probably figure the URL out, but it'd be ugly. Also, the MyFaces <h:dataTable> will not render an "id" attribute if you specify one. This is needed to verify tables and their data with jWebUnit.
• When using "ant reload" to reload my application (using Tomcat's Ant Tasks), I kept encountering a ThreadDeath error. This seems to be specific to MyFaces as I never saw it with other frameworks or Sun's RI.

Like Tapestry, I felt like I was banging my head against the wall a fair amount. However, with Tapestry (and all the other frameworks), I was able to get exactly the behavior I wanted w/o too much work. I could produce clean and user-friendly error messages - (Tapestry already had clean required messages built in). I was able to write a jUnitWebTest to test all CRUD activities. With JSF, I was able to test one thing - adding a new record. I couldn't edit it b/c the JavaScript support (which I tend to not use) puked every time it encountered a JSF-generated JavaScript function.

My opinion after all of this? If you know Struts, Spring MVC and WebWork are fairly easy to learn. WebWork is simpler and elegant, but Spring MVC supports more view options out-of-the-box. Tapestry is cool, but you'll have to invest a lot of time into learning it and you'll probably get caught up in its cult and forever be claiming "Tapestry Rocks!" which can get annoying to your fellow developers. Finally, I can confirm that SiteMesh rocks - it worked for all the frameworks I used and I never had to change a single line of code.

Whatever you do, don't use JSF. Not yet anyway.

RE: Why use Maven

Warner has a post about why he likes Maven. He might not know it, but he's actually ripping on AppFuse, its directory structure, and build file. I like getting ripped on, so that doesn't bother me. What bother's me is that Warner has comments turned off so no one can get him back.

The main reason that AppFuse uses Ant over Maven is speed. Maven runs much slower than Ant. Period. Also, with an open source project like AppFuse - I try to appeal to the larger audience, who likely has Ant installed. Other OS projects I work on (displaytag and struts-menu) both use Maven and people have a lot harder time trying to build from source b/c of Maven issues. Lastly, I like having a complete download - rather than download-dependencies-after-you-download-the-project like Maven does. I realize if I did use Maven I could package the dependencies in the app - which is likely what I'd do anyway since the main repositories seem to be constantly out-of-date.

Recently, I had a similar experience to Warner. As part of my current contract, I was tasked to write a couple of Maven sample apps. Warner came to my rescue and helped me out a lot, but I felt like I was jumping through a lot of hoops to do simple stuff that was already done in the Ant version of my app. I guess I'm just not a Maven guy. A project that's done right, regardless of if it's done with Ant or Maven, should build by typing "ant" or "maven" - or at least provide you help on what you need to type. Some projects, like Spring and Struts, actually allow you to use either one out-of-the-box. That's a pretty cool idea and likely keeps everyone happy.

It sounds like Warner has re-worked AppFuse to work with Maven. Care to donate your couple hours of work? I wouldn't use it personally, but there has been interest in a Maven version. Some folks seem to like slow build tools.

JSF: Which implementation should I use?

A few weeks back, Bill Dudney recommended I use MyFaces for my JSF app. He said it was less buggy than Sun's version. When I looked at MyFaces's website today, I noticed all their releases are betas - which is not a good sign IMO. Anyone have experience with either one? I think I'll go with Sun's as it probably has a larger community, and therefore more information.

I'm also hoping to use the JSF-Spring package. I was a little scared when I saw it's lack of documentation, but then I discovered it's in the JavaDocs if you scroll down. I'm not looking forward to the JSF's tag soup, but hopefully it won't be too bad.

My Tapestry Experience

I've finished migrating the sample app I'm working on from WebWork to Tapestry. You can also read about my WebWork experience. WebWork took me 2 full days to complete and the Tapestry version took me about 4. I had a bit of an advantage with WebWork as I've read a lot about it before working with it. I'm probably a bit biases against Tapestry because everyone thinks it's the bees knees - I don't mean to be harsh - I'm just reporting through the eyes of a developer. I'm sure I'll have similar gripes with JSF. Below is a list of things I discovered:

• There's something wrong with a project when its documentation is outdated and folks tell you to "Buy the book" rather than "read the documentation". On that same note, most of the documentation that does exist seems to be targeted at the advanced user.
• Like WebWork, there was no simple CRUD example I could look at. Then, like a ray of light from the sky - Warner published one yesterday! This tutorial vastly improved my productivity - thanks Warner! The only things I saw that I'd change in this tutorial is the use of individual setters vs. a domain object. Also, an ICallback is in the code, but never really used.
• The recommended way to name templates (.html) and page specification (.page) files is starting with an Uppercase letter. So rather than home.html (which most web developers are used to), it's recommended you use Home.html. Of course, this is easy to change - just seems like a weird recommendation, almost Apple-ish or Microsoft-ish.
• By default, all templates and pages are cached. Sure this is good because Tapestry is production-ready, but when you're developing - this needs to be off so you can get deploy+reload functionality. If you're using Tomcat, you can turn caching off by setting a $CATALINA_OPTS environment variable with value "-Dorg.apache.tapestry.disable-caching=true" (no quotes).
• Tapestry integrates with Spring very nicely. So easy it's almost silly. When I first created my list screen, it actually had only one line: public abstract UserManager getUserManager(); - and then I used OGNL to get my list of users: userManager.users. It doesn't get much easier than that.
• While setting success messages is fairly easy - I couldn't find a good way to prevent duplicate postings. With most frameworks, I stuff messages in the session and then retrieve them on the next page. With Tapestry, you have to throw a RedirectException if you want a true redirect (which requires a lot to calculate the URL of a page). I ended up using a PageRedirectException in hopes of simplifying this - but this seems to just do a forward instead of a redirect. In the few hours I spent on it, I couldn't find a way to save success messages and have them persist through a redirect. The reason I want to use a redirect is so a refresh of the page doesn't submit everything again. I know it's trivial, but is is an issue that most frameworks don't handle cleanly (except for Struts).
• There's no way to test Tapestry classes - since they're abstract, you can't just invoke them and test. Granted the classes are simple - but as long as other frameworks allow you to test their .java files and Tapestry doesn't - this will be an issue.
• When you first enter a blank form (i.e. to add a new user), the cursor's focus is put on the first required field. As a developer and user, I'd like to control this a little more (for example, by putting it on the first field). Furthermore, I'd like to control it easily - without having to subclass ValidationDelegate. On that same note, it'd be cool if required fields had an asterisk by default. WebWork does this and Spring/Struts can do this using Hatcher's LabelTag.
• There's no easy way to get the URL of a page - for example, to use in a <button>'s onclick handler to do location.href. I ended up having to implement a method in my page class, and a @Block in my template, setting the button's value with OGNL, and then using JavaScript to do onclick="location.href=this.value". The default components that ship with Tapestry only produce links and submit buttons (that must be in a form).

When developing this sample app, I often felt like I was banging my head against the wall. This is likely because I didn't want to take the time to truly understand how Tapestry works - I just wanted to get my app done. I did end up buying Tapestry in Action, but I probably won't read it until I have time or decide to use Tapestry on a project. I agree that Tapestry is cool, but it's certainly not intuitive for a Struts guy like me. I do look forward to working with it in the future and I'm sure I'll grow to like it more as I gain more experience.

Many thanks to Erik for his tech support and knowledge and to Warner for his nice kickstart tutorial.

AppFuse Changes: Unit Testing with Easy Mock and Spring's Struts Plugin

I have a couple of proposal for the next AppFuse release. Let me know what you think:

• Change service and action/controller tests to use Easy Mock to mock dependencies. This will likely require a bit more code in the test, but it'll allow true unit testing of components. Current tests are more like integrations tests, which tend to be slower. The Canoo WebTests will continue to act as the integration tests that verify functionality top-to-bottom.
• Change Struts to use Spring's Struts Plugin. XDoclet's Spring stuff should make this pretty easy so you don't have to modify any XML - just like the current situation. The advantage of this is you can use dependency injection on your actions, rather than getBean(...).

I hope to get these in, along with a WebWork option, in the 1.6 release. I'd love to get 1.6 done and released in August, but I'm probably dreaming since I'd like to finish Spring Live in the same time frame. Of course, I'm also planning on fixing any bugs that are currently entered.

My WebWork Experience

Yesterday I began converting a small application from Spring MVC to WebWork. By the end of the day I was pretty much finished, but shot an e-mail off the the user's list to figure out a few more things. Today was spent incorporating that knowledge and making the app follow more WW "best-practices". Below is a list of things I discovered:

• WebWork's documentation is actually quite good. I was able to figure out most things just by reading it. I'm still surprised that most web app frameworks don't describe a simple CRUD operation as their first example. In my experience, CRUD is 80% of a webapp's job.
• WebWork integrates with Spring quite nicely. It's interesting to see that Spring has most of its MVC Framework support as part of the core, but WW has its own. I wonder why? Who cares, it works!
• WebWork is a bit better than Spring MVC in that they have a mechanism for saving/displaying success messages. However, it doesn't live past a redirect, so you're still stuck putting messages in the session. Struts (as of 1.2.1) allows you to use a saveMessages(session, messages) call - and subsequent JSP tag to display (and automagically remove). Like it or not, Struts seems like the easiest solution for developers to use.
• There's no clean mechanism for cancelling validation when a user clicks on a "cancel" or "delete" button. Struts supports cancelling using it's <html:cancel> button and it's pretty easy to detect "delete" and cancel validation in a form's validate() method. I ended up using an onclick handler for my cancel button and not worrying about validation on delete. This is the way I did it with Struts for years. Spring is cool in that it has a processFormSubmission() method that you can override before validation kicks in.
• With Commons Validator, I'm used to specifying generic validation messages like "errors.required={0} is required.". This is possible with WW by using "errors.required=${getText(fieldName)} is required.". However, WW is a bit unique in that validation rules and ResourceBundles are defined on a per-action basis. I like having a central location for all my messages - like Spring and Struts have. I know it's possible with WW, but I'm trying to develop a "best-practices" sample app.
• I really dig that fact that you can use one JSP tag to render an entire <tr> in a table. This <tr> ends up having a label and an input field - which is very cool IMO. I did find some issues with the XHTML output, but found it very easy to submit patches. Good stuff.
• The config files (xwork.xml and validators.xml) must be in WEB-INF/classes. This is because they're XWork configuration files, and XWork is a non-web framework. It would be nice if I could put these in WEB-INF - where the rest of my config files (Spring, SiteMesh, etc.) reside.
• Many of the JSP tags require you to use "'literal value'" - where you put single and double quotes back-to-back. IMO, this is just ugly and I'd much rather put some sort of indicator that it's a dynamic value - i.e. ${...} or #.
• I couldn't get client-side validation to work. Seems cool though.

My experience with WebWork has been quite pleasant. I received excellent support from the mailing list - even though it took me a while to subscribe. The mailing list archives are woefully out-of-date, but this is a general java.net problem - not a WW issue. Maybe they should create a forum until the mailing lists get back on track?

Hopefully this last day and a 1/2 will make it much easier to implement WebWork in AppFuse. Thanks for the support gents - now I'm off to learn Tapestry!

DJUG: JavaServer Faces and Java Studio Creator

Tonight's DJUG meeting looks to be another dandy one. Bill Dudney is doing a talk on JavaServer Faces and Java Studio Creator.

This talk will take you through the basics of building a JavaServer Faces application. You will understand how to build a basic JSF application. We will build an application manually and then build it again with Java Studio Creator. If time permits, we'll compare the two implementations to identify when and how to use JSCreator effectively.

I'm mainly looking forward to it because I know Bill uses a PowerBook and Creator sucks on the Mac - even though Bill doesn't think so. Should be fun heckling him from the crowd. Of course, I'm also looking forward to learning more about JSF since I'll be using it next week.

[ANN] AppFuse Light 1.0 - a.k.a. Equinox

For those of you looking for an AppFuse Light, I have good news for you. I've actually been sitting on it for several months now, but now I'm prepared to release it. It's name is Equinox and it's much, much simpler than AppFuse. Equinox has only one build-time dependency (CATALINA_HOME being set for the servlet-api.jar). There's no code generation and no features - not even security. However, it supports building, testing and deploying from Ant, and even has support for managing Tomcat out-of-the-box.

To get started with Equinox, you can download the QuickStart Chapter from Spring Live. This chapter shows you how to develop a simple webapp using Struts, Spring and Hibernate - which talks to an HSQL database. Struts and Spring are integrated using the ContextLoaderPlugin and all tests are designed to be run out-of-container using JUnit and StrutsTestCase. Equinox ships with project files for both Eclipse and IDEA so you can develop and run the tests in either of these top-notch IDEs. There's also a demo available. Thanks to Boér Attila for the kick-ass CSS.

If you like what you see in the QuickStart Chapter, there's much more in the other ERP chapters of Spring Live - now available for download. Too see what's in the other chapters, checkout the Chapter Summaries.

This is a nice milestone - feels good to have made it this far. Have a good weekend!

My Job for the next couple of weeks

I can't help but brag about how cool my current gig is with Open Logic. My task for the next few weeks is to write a simple sample app - and create alternative MVC implementations. Targeted frameworks include Struts, Spring MVC, WebWork, Tapestry and JSF. Not only am I working from home, but they dropped off an AMD XP 2800 to work with. Installing Fedora Core 2 with VMWare is what I'm up to this morning. Working with open source all day - it doesn't get much better than this.

Jetty and WebSphere suck, JRun and Tomcat rule the pack

I've been looking for an app server performance comparison for some time now. Maybe those folks that say Tomcat sucks and Jetty rules will change their tune. Via Lasse Koskela:

Web Performance Inc. has published a very interesting report, which included a couple of surprises. Jetty pretty much sucked, JRun was one of the top guns, and Tomcat wasn't too far behind JRun.

Anyone know of any similar (recent) comparisons?