Raible Designs

Use Tapestry in AppFuse

Lee Grey shows how to integrate Tapestry into AppFuse. Good stuff Lee. I can't wait to pump out the the WebWork version of AppFuse so I can start on Tapestry integration. Then again, I do have it on the roadmap to take a break after 1.6. I hope to release 1.7 (with Tapestry) in early November. As for JSF, I think I'll wait until next year.

One thing's for sure

The Java Community certainly does care about JSF. Regardless of whether folks like it or hate it - there's definitely a lot of opinions! Who woulda thunk a simple blog entry would get so much traffic? Wierd.

You know it's a late night when Erik posts before you go to bed...

Should I ditch Tiles in AppFuse?

I've haven't been developing applications with AppFuse since May. Instead, I've been using Equinox. One of the main things in Equinox I've grown to love is SiteMesh. It's worked in all the webapps I've written, which utilize frameworks like Struts, Spring MVC, WebWork, Tapestry and JSF. Tiles will only work in 3 of those.

I think it's time to make an executive decision on AppFuse and ditch Tiles in place of SiteMesh. It's faster and easier to develop with, and it doesn't get in your way. In fact, I didn't have to change a single line of SiteMesh-related code to support any of the aforementioned frameworks. Furthermore, using SiteMesh would also greatly reduce the duplicate between frameworks. I've thought about keeping Tiles around, but it's a pain in the ass to maintain parallel sets of documentation.

Whaddya think - any reason you can think of to keep Tiles? I can't. In fact, I think I'd cringe if I had to start my next AppFuse-based project w/o SiteMesh.

David Geary - the JSF guy?

I wonder if this David Geary is the JSF Geary. I hope so, it'd be great if he started blogging. I've seen David speak before and he's definitely good. Regardless of my recent experience with JSF, it's a technology that's likely to succeed. David is a JSF expert - so hopefully he'll have some tips and tricks for us.

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.

The Joy of developing with JSF

I plan to write up a "My JSF Experience" post later today, but first, I'm forced to rant on the state of JSF implementations. First of all, I must say that JSF isn't so bad. It's cool how you can map buttons to "actions" defined in a navigation entry, as well as to call a method in a managed bean. The problem that I'm experiencing is that the JSF implementations, both from Sun and MyFaces - are errrrr, not so good.

I actually managed to almost finish my simple JSF sample app in one day, but then decided to shoot off some questions to see if I could resolve some remaining issues. Then based on feedback I received, I decided to switch from Sun's RI to MyFaces - not only for the "sortable" grid (I still don't know if it exists), but also Spring supports it w/o using an add-on library.

Ever since I switched, things just haven't gone right. First of all, MyFaces, requires your implement a <listener> in web.xml - who knows why, but you get an error indicating you need it if you don't have it. Standard JSF doesn't require this - why does MyFaces?

OK, I can deal with adding the listener. Everything works as with Sun's RI - and even better since the "layout" attribute of <h:messages> actually works. BTW, why isn't "div" a choice instead of "table" - whoever designed these choices obviously still uses Netscape 4 and table-based layouts. I'm happy now. MyFaces seems to solve the duplicate post issue so if you refresh after adding a record, it just shows a blank form. Cool, I can live with that.

One problem I found, that likely exists in both implementations, is that it's a true pain-in-the-ass to get a declared ResourceBundle in a managed-bean. Here's the method I'm currently using to add a success message:

    public void addMessage(String key, String arg) {
        ApplicationFactory factory = (ApplicationFactory)
            FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
        String bundleName = factory.getApplication().getMessageBundle();
        ResourceBundle messages = ResourceBundle.getBundle(bundleName);
        MessageFormat form = new MessageFormat(messages.getString(key));

        String msg = form.format(new Object[]{arg});
        FacesContext.getCurrentInstance().addMessage(null, 
                new FacesMessage(FacesMessage.SEVERITY_INFO, msg, msg));
    }

There has to be an easier way! Please tell me there is. I admit that I'm a JSF rookie - having just started using it two days ago, but it seems ridiculous that all the "success message" examples out there don't even consider i18n.

So now I have my success messages working, but I discover that there's no way to escape HTML (using <h:messages>) from my ResourceBundle (to put bold around a part of the message). ALL of the other MVC frameworks I've been dealing with allow this - why doesn't JSF?! Again, I'm hoping someone tells me I'm ignorant and there is a way to do this.

Lastly, I tried to upgrade to the latest MyFaces snapshot from CVS to solve this bug and now I can't even get my fricken app to start up because of this issue. Are these the hoops that developers have to go through to get started with JSF? Thump, thump, thump. My head is starting to hurt.

Update: I'm an idiot about the "can't get my app to start thing" - I didn't copy all the new myfaces*.jar files into WEB-INF/lib. Heh.

BTW, MyFaces requires a whole slew of JAR files just like Struts. Here's my current inventory:

  commons-codec-1.2.jar
  commons-collections-3.0.jar
  commons-digester-1.5.jar
  commons-validator.jar
  commons-oro.jar
  commons-logging.jar
  jstl.jar
  myfaces.jar
  myfaces-components.jar
  myfaces-jsf-api.jar

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.

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!