Raible Designs

Facets of Ruby by Dave Thomas

You can learn Ruby in 4 hours. This talks isn't to learn Ruby, but rather to show facets of Ruby. Ruby has made programming fun again for Dave. It's also made him more productive.

Languages and tools make a difference

Ruby has variables, methods, but no types in methods. When Dave first started using Ruby, he had a strong typing background - and was terrified of Ruby's un-typed feature. He first thought Ruby was a toy language for hobbyists because of the lack of typing. Now, many years later, he really likes the lack of typing and hardly even has bugs relating to typing. He notes that with Java we store most of our data in Collections - and those are all Objects - so Java is essentially un-typed as well. How often do you get ClassCastExceptions? The rooms concensus is not not a whole lot. To make up for the lack of typing, Ruby developers tend to write a lot more unit tests.

ActiveRecord - Ruby O/R Mapping Library

Ruby on Rails - not a single line of XML. Uses intelligent defaults and allows you to override them. The following creates a wrapper around the "ranks" table.

class Rank < ActiveRecord::Base
end

The original author of RoR thinks that every database table should be plural, so singular class names map to plural table names. It's even smart enough to change Person to a "people" database table. Apparently it has a bunch of the singular-to-plural mappings for the English language built-in. The key to Rails is clever defaulting - allow you to write a lot less code, but override if you really need to.

ActiveRecord has many lifecyle hooks (17) that you can override. For example, before_save, before_destroy, validate. For example

def before_save
  self.when_added ||= Time.now
end

I wonder if Rails has any support for transactions and specifying propagation behavior on transactions? I asked Dave this question and it sounds like ActiveRecord has a rich support for transactions - and even wraps the "save" method with a transaction by default.

"Ruby is pretty damn good at web applications"

Simple CGI is a common choice. FastCGI and mod_ruby in Apache are other common choices. There are also a number of different web frameworks for Ruby:

1. Roll-your-own
2. Templating systems
   1. erb
   2. Amarita
   3. RDoc templates
3. Iowa - similar to WebObjects
4. Ruby on Rails

Ruby on Rails - MVC Framework

Contoller - one method per view. Setup context (a.k.a. the model) for views. Views contain "rhtml" - HTML with embedded Ruby. Lots of helper functions. Can access model data (context) setup by Controller. The name of the method in the Controller determines the name of the view file. A "select" method will dispatch to a "select.rhtml" file. The method name to call in a Controller is determined by the URI - for example, /ranks/view calls the "view" method in the RanksController class. Pretty slick! I like the idea of smart defaults - IMO this should be used a lot more in webapps. I'd love to get away from mapping URLs in Struts, Spring and WebWork.

Rails has built-in support for configurable URLs - so you can change query strings to more slash-type URLs. What about things like client-side validation, success messages and sortable/pageable tables? Do those exist in Rails? I asked Dave and he said said they have good support for success messages with a "flash" concept and the post-to-redirect problem is almost non-existant because most controller invocations are redirects. Client-side validation and sortable/pageable tables don't exist in Rails.

Rails has Needles - and IoC framework similar to Pico. However, there's a fair amount of traffic on the mailing list and a lot of Ruby developers think they just don't need IoC. Dave's suggestion is to use Class Injection.

The largest Ruby application is probably Daves - 55,000 lines or code, couple hundred thousand users. There are entire companies who write all all their applications in Ruby. The founder of Rails wrote it so he could write Basecamp - which is only 4500 lines of code.

Good stuff Dave - and definitely a nice overview of Rails. Will I be digging in an using Rails anytime soon? Not this year, I'm going to have some fun with Tapestry and JSF first. Maybe next year.

Comparing Web Frameworks Presentation

Since Kris let the cat out of the bag, I might as well give you the link to my comparing web frameworks presentation (PDF, 280KB). I also created a page on the Equinox site for this presentation and related materials. In addition to the presentation, this page also has links to the various framework implementation demos. Here they are for your convenience:

• Spring
• JSF
• Struts
• Tapestry
• WebWork

Kris notes that I would still choose Struts. I think it should be noted that I would only choose it in combination with AppFuse (which generates ActionForms). Same goes for Spring and WebWork. I've added interceptors and convenience methods that simply make developing with these frameworks faster and easier. I would've chosen WebWork for my current project, but I'd like to see better client-side validation. Spring needs better tag libraries.

I think the choice of what framework to use is a very personal thing. I think the "best" framework for one person might be very different for someone else. For me, I typically do short-term projects with clients - get them up and running with an application, and then head off to the next project. It makes sense for me to create applications that use a popular framework like Struts that they can easily find developers to maintain it. However, the one thing I'm starting to find is that as long as I use AppFuse - there's good documentation on how to do things. So I've already written the "how to develop and extend this app" for future developers of a client's application. This will (hopefully) open the door for me to use any web framework that AppFuse supports.

I think WebWork rocks, but it's similar to JSF in that it doesn't come with everything your need. The good news is it's easy to write interceptors, but IMO there's a few that should be part of the framework. After working with Tapestry and JSF, I can see how component-based frameworks will be the wave of the future. I think as you develop more and more components, the code you write becomes less and less. It's funny that this is one of the goals of AppFuse - incorporate a bunch of tips and tricks for various frameworks to make development easier. By adding support for Tapestry and JSF, hopefully AppFuse will someday become a repository of useful components. Documentation is good - code is better.

I'd probably be more enthusiastic about Tapestry and JSF if I knew more about them. I still have a lot to learn. I've bought the books (Tapestry in Action and Core JSF), I just haven't had time to read them. I think after incorporating these frameworks in AppFuse (hopefully this year), I'll get a better feel for them and how they make development faster and more efficient. My major problem with JSF is that it's being written for the tools vendors and not for the developers. Make it easy for everyone, not just folks that want to use their hammer-like IDE to develop webapps. The major problem I have with the JSF Tools is 1) none of them are free and 2) most of them are tied to a proprietary app server.

[ANN] Equinox 1.1 Released

In preparation for my talk on comparing web frameworks, I've made a bunch of enhancements to Equinox. I changed the default web framework to be Spring and added a very simple "CRUD users" feature. While it's basic, it shows how to do validation, success messages, and a sortable list with the following frameworks: Spring, JSF, Struts, WebWork and Tapestry. I even added a "birthday" field to demonstrate date-handling. I dig the built-in popup calendars that ship with JSF and Tapestry.

• Download
• Demo

Oh yeah, I also added a hack (from James Violette) to make the Display Tag work with JSF. Code says it best. I plan on writing a detailed how-to as part of the Display Tag's documentation. Suggestions for a cleaner hack are welcome.

In other display tag news, here's another way to do static headers.

Trails - like Rails, but with Tapestry, Spring and Hibernate

I've been thinking about Rails ever since I wrote a post about it on Monday. The main reason is because of Dion's comment:

Matt - You should follow the lead and do a video of setting up a simple app using AppFuse.

This might sounds like a good idea, but if I did it right now in AppFuse's current state, it'd be a disaster. The reason? Because you have to manually create a whole bunch of classes to do CRUD on a database table. Here's a list of new classes needed for adding a new "person" table.

• model.Person
• dao.PersonDAOTest
• dao.PersonDAO
• dao.hibernate.PersonDAOHibernate
• service.PersonManagerTest
• service.PersonManager
• service.impl.PersonManagerImpl
• webapp.action.PersonActionTest
• webapp.action.PersonAction
• web/pages/personList.jsp
• web/pages/personForm.jsp

The last two JSPs can be generated, but that's still a buttload of classes (9) just to CRUD (and test!) a database table. Not too mention all the files you need to edit for Spring and i18n.

• dao/hibernate/applicationContext-hibernate.xml
• service/applicationContext-service.xml
• test/web/web-tests.xml
• web/WEB-INF/classes/ApplicationResources_en.properties
• web/WEB-INF/menu-config.xml

Result: to CRUD a database table using AppFuse you have to create 11 new files and modify 5 existing files. 16 files. What a beotch, huh? If I made a video of this - it'd be 20 minutes long! While this might make AppFuse look silly, it's really more of a symptom of the patterns we have in J2EE and how we're supposed to architect our apps. 3 tiers, test-driven, loosely-coupled and internationalized. Of course, if I was focused on fast and efficient, I could do this all with 1 JSP and JSTL's SQL tags. Everyone would slap my hand for not following patterns, but I'm willing to bet it'd work just as well and be just as fast. But I digress.

There have been a fair amount of requests (and some patches submitted) to generate and modify all of the files listed above. For the most part, I've frowned upon adding such a feature because I think if folks can run "ant generate -Dmodel=Person" - they'll end up with a whole bunch of code that they know nothing about. Sure there's the tutorials, but folks will quit reading those. Instead, they'll create a whole slew of POJOs (maybe even using Middlegen) and run "ant generate" on all 50 of them. Poof - now they've got 550 new files to maintain. Talk about a maintenance nightmare. Even worse - a support nightmare for me.

Nevertheless, if I wanted to create a cool video for AppFuse, I'd spend a few days writing this code-generation engine. Then I could show how you could create the data, service and web layer (including UI) in a matter of seconds. It'd be cool and folks would dig it. I'm still considering it, but I'm also leary of the resulting support fiasco. Maybe I could just say "use at your own risk".

A while back, I saw Erik Hatcher suggest a better solution than code-generation. I can't remember what he called it, but it was something like "meta-data dynamic rendering". The idea is that your application reads the metadata of a table (or POJO) and renders the appropriate UI for it. I loved the idea as soon as I heard it. I've always wanted a way to dynamically render the UI rather than writing HTML. Of course, I still want the ability to edit the templates and HTML since I fancy that sort of stuff. I don't like writing HTML for each row in a form, but I do like tweaking the HTML and CSS to look good.

Earlier this week, I saw the concept in action with Rails and its demo. IMO, something like Rails would never fly in Java because it appears to be tightly coupled to the database and only MySQL, PostgreSQL, and SQLite are supported. The Java community always seems to pride itself on database abstraction, partly due to JDBC and its ability to connect to anything that has a JDBC Driver. Ruby will probably catch up someday, but right now it appears to be looking for something like JDBC.

Then along comes Trails, which made me smile earlier today when I first read about it on the tapestry-dev mailing list.

I've been working on a project called Trails that uses Tapestry quite heavily and I thought it time to start soliciting feedback. Trails is a domain driven development framework that uses Tapestry, Spring, and Hibernate. Trails is very much in it's infancy, but the current version is functional and should give people a rough idea where I am heading. It's my first real forray into Tapesty and I have really found Tapestry a joy to work with.

Trails is very much like Rails, except that it doesn't talk directly to a database table. Instead, it talks to your domain objects that you mark up with XDoclet/Hibernate tags. To test it out, I dropped a User.java file into the org.trails.demo package, marked it up with XDoclet and deployed. It didn't work at first because the .hbm.xml files are explicitly listed in Spring's applicationContext.xml. I changed the "sessionFactory" bean to use the following and wammo - success! I could list and CRUD the table that my User object was mapped to.

  <property name="mappingDirectoryLocations">
    <list>
      <value>classpath:</value>
    </list>
  </property>

Trails is very cool, and I'd love to incorporate it into AppFuse or Equinox. Does an LGPL license allow me to do this? The one problem I can see with adding it is that it's specific to Tapestry and Hibernate, which doesn't always suite folks. I think developers might be willing to change because this solution will vastly improve their development productivity, but who knows. I think the best solution would be to offer this option in AppFuse/Equinox, but also offer the current manual and code-generation options. The holy grail would be the ability to plug in iBATIS or JDO instead of Hibernate. In addition, using Struts, Spring, WebWork or JSF instead of Tapestry would have folks clammering to use this stuff.

Mad props to David Heinemeier Hansson and Chris Nelson - you guys are developing awesome software.

Rails - the MVC Framework for Ruby

When I first saw the quick setup for Rails video, I dismissed it as a something simple that wasn't that cool. Thanks to Dion's post, I decided to watch it again. Then I realized why it looked so simple the first time - the video kept looping and all I saw was the Apache setup part - I didn't see the whole video. After watching the video this morning, it's enough to make me want to become a Ruby developer and use Rails to develop my next webapp. Then again, Ruby probably doesn't pay the bills nearly as well. The upside is it looks like it would actually run fast on OS X instead of the dog-slow Ant/Tomcat/Eclipse/IDEA combination.

Hopefully I'll get to learn more about Rails at Denver's upcoming No Fluff Just Stuff. It looks like Dave has added it to his repertoire. I wonder if Rails has support for using the Copeland IoC container?

Comparing Web Frameworks: Presentation Outline

My Comparing Web Frameworks outline is due to the ApacheCon Planners today. I spent a couple of hours putting it together this morning and I'm mostly done. In reality, I know that I won't cover the things that everyone wants to know. In an ideal world, I could simply target the presentation towards people like me: they know Struts but want to learn more about the other frameworks. Before diving in, they want to know some things to watch out for.

The problem with doing that is writing for people like me sometimes backfires. I'd like to make it an advanced presentation, but I'm not an authority on all 5 frameworks - so that seems a bit far fetched. However, if I could add Tapestry and JSF support to AppFuse in the next two weeks - I'd have a lot more experience to refer to. But that ain't gonna happen - the first update chapter for Spring Live is due next week. OK, enough rambling - here's the slide titles I've come up with. So far, it's 22 slides and shouldn't grow any since it's supposed to be finalized when I submit it.

• Who is Matt Raible? My background, open source involvement, etc. Trying to give myself some credibility.
• Framework Experience: Long time Struts user, used Spring since end of last year, developed apps with other three this summer. AppFuse supports Struts, Spring MVC and WebWork; Tapestry and JSF coming before end of year.
• Meet the Candidates
  • Struts: Pros and Cons. Pretty much a standard, lots of examples, HTML tag library kicks ass. ActionForms kinda suck, can't unit test (only StrutsTestCase integration tests), Mailing list is swamped.
  • Spring MVC: Nice lifecyle (for overriding binding, validation, etc.) integrates with many view options seamlessly, IoC for easy testability. Not widely used, requires lots of code in JSPs, almost too flexible (no parent controller for SimpleFormController and Controller).
  • WebWork: Simple architecture, tag library easy to customize, interceptors are pretty slick. Documentation only recently written, few examples, client-side validation needs work.
  • Tapestry: Very productive once you learn it, templates are HTML (great for designers), healthy project. Documentation very conceptual, rather than pragmatic (lots of "read the book"). Steep learning curve, few examples. Impossible to test - page classes are abstract.
  • JSF: J2EE standard (lots of demand and jobs), fast and easy to develop with, rich navigation framework. Tag soup for JSPs, a bit immature (doesn't come with everything), no single source for implementation.
• Controllers and Views: Show controllers for all 5 frameworks and template page (JSP/HTML) for forms. Give URL to download sample apps.
• List Screens: How easy is it to integrate a sortable/pageable list of data? Struts, Spring and WebWork can use tag libraries like the display tag, value list or data grid. Tapesty has contrib:Table. JSF has dataTable component that requires custom logic for sorting (let me know if this has changed).
• Bookmarking and URLs: Struts, Spring and WebWork give you full URL control. Tapestry has ugly URLs. JSF does a POST for everything. Conclusion: first 3 play nicely with container-managed authentication. Tapestry doesn't (although there's a patch for pretty URLs). JSF is not friendly to bookmarking.
• Validation: Struts and Spring MVC can use Commons Validation - a mature solution. I've heard it's architecture is ugly, but who cares - it works! WebWork uses OGNL which allows powerful expressions. Client-side support is new and maturing. Tapestry has robust validation w/ good messages out-of-the-box. JSF has ugly default error messages, but is the easiest to configure.
• Testability: Struts you can use StrutsTestCase, which requires web.xml and struts-config.xml. WebWork and Spring allow easy testing with Mocks. Spring has a spring-mock.jar that can be used for mocking the Servlet API with any framework (it's not Spring-specific). Tapestry is impossible to test because page classes are abstract. The argument I've hard is "you don't need to test them b/c they're so simple." JSF page classes can be easily tested and actually look a lot like WebWork Actions (except they don't extend anything).
• Success Messages: The easiest way to solve the duplicate-post problem is to redirect after doing a POST. Struts is the only framework that allows for success messages to live through a redirect. It's fairly easy to get i18n messages in a Struts Action. Spring has nothing "built-in" for success messages. Long classnames / method arguments make it kinda clunky to get messages. WebWork has the cleanest way to get messages using a simple "getText()" method. Both require a custom solution to make your messages live through a redirect. Tapestry requires you to throw an exception to redirect and it still doesn't redirect (I haven't solved the duplicate post problem with Tapestry). JSF requires lots of code to get a ResourceBundle, but you could use Spring's IoC to inject a "messageSource" bean, making it a lot easier. JSF requires a custom solution for messages to live past a redirect.
• Spring Integration: Supported by all, sample apps have examples (quick slide).
• Internationalization: JSTL's <fmt:message> tag makes it easy in all JSP-supporting frameworks. Too bad there's not a standard for getting bundles in controllers and setting messages. Struts, Spring and JSF encourage you to use one ResourceBundle for all messages while WebWork and Tapestry encourage separate files for each page/action. This strategy is probably better for large teams.
• Page Decoration: I used to be a huge advocate of Tiles (using it since August 2001). SiteMesh is much easier to setup and use. Tiles can be used in Struts, Spring MVC and JSF. SiteMesh can be used with all 5 frameworks. In fact, the sample app uses the same SiteMesh setup for all w/o changing a thing. SiteMesh requires no maintenance, Tiles requires you add entries to tiles-config.xml whenever you add a new page.
• Tools: Struts has lots of tools available for it and even frameworks built on top of it (i.e. Beehive's NetUI/PageFlow). Spring has Spring IDE which is really just an XML tool for validating your bean and their relationships. WebWork has none (that've been released), but it is on the roadmap. Tapestry has Spindle, which is great for code-level programmers. It doesn't do drag-n-drop, but it does validate relationships between files. JSF has lots - but all of them cost money and tend to hook into proprietary app servers.
• Business/Marketing: Struts has lots of jobs and is well-known in the industry. A lot of enterprise applications are based on it. Spring is getting more press, but mostly because of the framework's other features. Knowing the rest of Spring is more valuable than Spring MVC. WebWork is gaining ground, but it's still virtually unheard of on job boards. If you do get gigs using WebWork, it's likely word-of-mouth and you'll probably be working with some pretty smart people. Often used with Spring and Hibernate. Tapestry needs more marketing - no one has heard of it, hence no jobs exist for it. JSF is quickly becoming the most popular. Want to stay employed? Learn JSF. The best reason: so you can back up your arguments on why you do/don't like it.
  
  Dice Job Count: Struts (1006), Spring (15 - not a very good name for searching, used "spring framework"), WebWork (14), Tapestry (9), JSF (147).
  
  
• My Opinion: You have to come to the conference for that . Slides should be posted following my presentation.
• Resources: Link and such for downloads, frameworks and tools mentioned.

Comments, suggestions, like it/hate it? Let me know. I expect to send this in in a few hours - so you'd better be quick!

I don't hate JSF

I'm still amazed by all the traffic and comments received by my experience with JSF. In some cases it feels like I insulted some of these guys wives or something. Here's some good quotes from the comments:

The less than positive experience is because Matt wants to write an app while asking a million questions all over mailing lists and not investing the time to learn.

I think you're too in love with struts to have a clear sight on what's going on.

Pick your poison and stop bad-mouthing others because you don't get.

I admit that I was a bit harsh on JSF in my post. Here's why. I developed 5 simple apps this summer, all doing the same thing with different frameworks: Struts, Spring MVC, WebWork, Tapestry and JSF. All of them hooked into the same backend, which was Spring+Hibernate. I had a learning curve to overcome with WebWork, Tapestry and JSF. I already knew Struts and Spring MVC, so those versions where easy to develop with. Of the three (WebWork, Tapestry and JSF), I was able to complete the JSF version the fastest. It took me a 1 1/2 days for WebWork, 3 days for Tapestry and 1 day for JSF. Or so I thought.

The JSF app was pretty close to being finished, but I was missing one thing - a sortable/pageable table. And I hadn't written the test for my page classes yet. This was Wednesday. I made a post late that night on how much I liked the JSF-Spring integration library. If you'll notice in this post, I mentioned that I got the displaytag to work too (almost). I found that I had to use an empty tag to pull the list of users from my page bean into the request, and then the displaytag could render the list. This was almost perfect, but the <h:commandLink> didn't work, so I had no way of editing a record from the table.

At this point, it all started to break down - and my frustration began. I was sooo close to completing this application and so far (even with the minor snags I'd hit) it was the easiest one to develop. Juergen left a comment stating that Spring's core now had a DelegatingVariableResolver in its core. So I figured I'd make my application more "pure" and use that instead of the JSF-Spring integration library. This was my first mistake. The DelegatingVariableResolver from Spring didn't work with Sun's RI and only worked with MyFaces. I figured it wouldn't be hard to switch (JSF is a standard, right?) - so I went to it the next day. I'd also heard that MyFaces had a sortable/pageable dataGrid - so the switch seemed like a good idea.

The first bump in the road was that while the DelegateVariableResolver worked, MyFaces reported an error. The Spring guys blamed MyFaces and MyFaces blamed Spring. Result: it's a bug that no one will fix. I spent a couple hours being a good open-source citizen by 1) trying to fix it and 2) reporting it. The second bumb in the road was that I had to change a few things that worked in the RI but didn't work in MyFaces (I forget what now). However, this wasn't so bad since it also fixed a couple of issues.

Next I tried to use MyFace's <x:dataTable> to replace the display tag. Since it had a sortHeader component, I figured this would be easy. It turns out this component requires you to implement custom logic in your page bean. Things might've changed since July, but I doubt it. Lastly, aftering getting everything to work, I went to work on writing a jWebUnit test to test it all. While doing so, I found that it was almost impossible to test my edit screen. With other frameworks, I could specify a URL with a record id and then proceed to change form fields and push buttons. With JSF, there was no easy way to determine the URL. The rendered UI used heavy JavaScript and when you clicked on a link in the dataTable, this called a JavaScript function. I have no problems with JavaScript and I think it's a great technology. However, the current UI testing frameworks I use (jWebUnit and Canoo WebTest) use the Rhino JavaScript library (js.jar) and it sucks at JavaScript. It reports errors where there are no errors - and hence, I tend to exclude the JAR and disable JavaScript support in my tests. If there was better JavaScript support in these testing frameworks - I'd likely have to problems with JSF's "I post for every link" mantra.

In most of my development life, I've most often been a framework user rather than a developer. This means that if I find problems, I don't extend the framework - I look for other solutions. Call me whatever you like, but I'm just trying to get my job done and the project completed. I don't want to mess with the internals of a framework to make that happen. With JSF (and Tapestry too), you have to be more of a framework developer. You have to be willing to create your own components. These frameworks are designed as component frameworks and they want you to extend them. That's one of the major points of their architecture.

So here I am again, posting about JSF - which will undoubtably get an incredible amount of hits just because it has "JSF" in the title. Why? Because you can't ignore JSF. Even if you don't want to develop with it - there's going to be tons of jobs that require JSF in the near future. In fact, there are already quite a few. Surprisingly enough, in my job search last month, I has a more opportunities for JSF (and WebWork suprisingly enough) than Struts. Finding a Tapestry gig - good luck. Of course, I'm a consultant, not an employee - so I don't often don't get to choose frameworks for companies.

I think JSF is an immature technology that will rapidly mature. I hope it does b/c it was fairly easy to develop with - there were merely some minor bugs in the two implementations. These can be fixed. In reality, I think we should all quit bashing on JSF and jump in to try and make it better. Rather than complaining, let's try to help.

I've done my part and applied to be on the JSF Expert Group. They probably won't let me in though - everyone seems to link I hate JSF. If I had my way, I'd scrap the sucker and make Tapestry the JSF standard.

Comparing the Big 5 Web Frameworks

My session at ApacheCon is titled Comparing Web Frameworks: Struts, Spring MVC, WebWork, Tapestry & JSF. I have to turn in my presentation by Friday. The purpose of this post is to get your feedback and see what you'd like to see in such a talk. Here's the abstract:

This session is designed to explore the popular Java web frameworks. It will briefly explain how each one works and the strengths and weaknesses of each. Tips, tricks and gotcha's will be plentiful. A simple web application will be dissected and the different options will be compared. Lastly, it will provide attendees with a sample app they can download that has options to use any of the frameworks described.

The simple webapp is MyUsers from Spring Live. As part of my gig with Open Logic this summer, I wrote a number of sample apps using Equinox. Among these where 1) a Mavenized version, 2) a Tapestry version, 3) a JSF version, and 4) WebWork version. The Struts and Spring MVC versions were already done as part of the book. They agreed to let me use the code and knowledge from that experience. This is all to say it shouldn't be too hard to create the sample app for this talk.

The hard part is going to be talking about things that developers care about. In my post on JSF a while back, I noted the things I typically want in my webapps. The following topics might make good points of discussion.

• A sortable/pageable list of data. It's possible, but you have to add special sorting logic for each class. JSP already has this with the display tag - I'd simply like to be able to use it in JSF.
• Bookmarkability. Container managed authentication gives us a great way to offer users the ability to bookmark pages. If everything is a POST with JSF, we lose this ability. Sure there's the HTMLOutputLink, but if we can't invoke actions, what good is it?
• Clean and easy to read validation messages. The validation messages in both MyFaces and Sun's RI are not something you'd deliver to customers. What's wrong with making clean messages out-of-the-box? Tapestry seems to have no problems doing this. All the other MVC frameworks make you specify your own - which is fine with me.
• Easy cancelling and multi-button form handling. JSF does this well - better than the rest I'd say.
• Easy testability. Because of the plethora of JavaScript, JSF apps are difficult to test with tools like jWebUnit and Canoo's WebTest. Don't get me wrong, I love JavaScript - but an application should be able to be tested w/o it.
• Success Messages. JSF does success messages OK - it's a pity it's not easier to get a resource bundle and it's a shame that you can't escape HTML in the <h:messages> tag. This seems like an oversight to me.

I could do a number of slides and show how each framework handles the above situations. Other topics that would be worthwhile would be:

• Model in View - can you use your model objects to back forms or do you have to use something like ActionForms?
• Spring Integration - all of them have this. This would merely be a discussion on how its handled.
• Validation - how robust and/or extensible is it? How hard is it to do chained validation? What about client-side validation? Is the client-side stuff immature like WebWork's?
• Internationalization - how is it done and how hard is it to get messages in your classes? JSF sucks at this.
• The Duplicate Post Problem - how does it handle duplicate posts. Not the "push the submit button twice" but the "hit refresh after saving" kind. Tapestry fails this test.
• Page Decoration - SiteMesh can be used for all frameworks, Tiles for some. Discuss how much easier it is to use SiteMesh.
• Tools - since some frameworks have tools to help ease there development and others don't.
• Business/Marketing - how well known is the framework and will your skills be marketable if you learn it? JSF and Struts are in high demand. Tapestry is virtually unheard of. WebWork is for the evil few (heh!) and Spring MVC is the new kid on the block.

Whaddya think - what is so special about your framework that'll make it look better in my talk? What are the things that suck that I can bash on? If you're a committer on one of these frameworks - are you going to be at ApacheCon? I'd love to have some folks defend their projects after I'm done ripping on them. If I don't rip on yours, then you can bask in all its glory.

If you live in Denver, I'll be delivering this presentation at DJUG's Architecture SIG on November 3rd.

[ANN] AppFuse 1.6 Released

After many late nights and lots of Red Bull - AppFuse 1.6 is finished. Phew! The major additions to this release are SiteMesh and WebWork. I also did a lot to simplify DAOs and the tutorials. This release is definitely the largest AppFuse one I've ever done - or at least I spent the most time on it. Not only was WebWork added and Spring MVC improved, but I improved the Struts version significantly too. Now it'll handle nested objects, which can translated into nested forms - and validation even works. All classes in the "web" module can now be tested sans-container, which eliminates the need for Cactus and reduces test execution time by over 50%. The relationship between users and roles was also re-worked to take advantage of Hibernate's slick parent-child relationship features.

• Download
• Release Notes
• Learn more about AppFuse
• Live Demos:
  • Struts + Spring + Hibernate
  • Spring + iBATIS
  • WebWork + Spring + Hibernate

See the QuickStart Guide and Tutorials to get started right away. Enjoy!

AppFuse 1.6 almost done

I spent many hours and quite a few late nights this week working on AppFuse. It's funny how little sleep you can live on when you're working on something you're passionate about. There's only a few items left on the 1.6 roadmap, so I hope to do a release in the next week or so.

The major new feature in 1.6 is WebWork as a web framework choice. If you'd like to dig in and take AppFuse+WebWork for a test-drive, checkout AppFuse from CVS and execute "ant install-webwork". From there, the tutorials are a good place to start. The QuickStart Guide has more detailed instructions.

If you don't want to do the DAO and Manager stuff, and you'd rather just dig into WebWork, you can download the files from the first two tutorials and extract them into your project.

For a complete list of changes (so far) in 1.6, see the README.txt in CVS. You can also checkout the following demos:

• Struts, Spring and Hibernate
• Spring MVC, Spring and iBATIS
• WebWork, Spring and Hibernate

I'll try to write up a detailed post about my WebWork experience in the next couple of days. In the meantime, let's just say I dig it.