Raible Designs

AppFuse Tapestry/JSF Status

There's 3 phases of adding a new web framework to AppFuse. The first phase is integration and configuration. This is the fun part and involves adding JARs and configuring everything so the framework actually works. At the end of this phase, I'm usually pretty enthusiastic about my progress and think I can finish the whole project in a few more days. Then comes the "features" phase, when I start coding AppFuse features with the framework. This part always takes wwaaaaaaayyyy longer than I anticipate. This is the part where I realise previously done things (from other framework implementations) won't work and I have a long road ahead of me. For instance, with Tapestry and JSF, I have to figure out how to do the following: Country drop-down based on locale (currently a JSP tag, so should work with JSF), multi-select checkbox, and placing an asterisk next to required fields.

The asterisk isn't too hard if you do it the "WebWork way" - where you simply specify required="true" on JSP Tag. However, I'd prefer to have it read from the validation engine, so this will probably take some digging on how to do it with JSF/Tapestry. For the country drop-down, I'll probably have to create a Tapestry Component. I believe both frameworks have a multi-select checkbox component. After working with Tapestry's contrib:Table component for a few hours, I miss the Display Tag. The contrib:Table works, but it's a LOT more difficult to configure than the Display Tag. It also blows up if you click the column headings too many times. Also, it doesn't have any exporting features like the Display Tag. Sure, it might not need them, but a lot of folks have come to rely on these and it's a handy feature. Furthermore, another unfortunate thing I found in Tapestry this morning is it doesn't seem to read the locale from the request. So if you change your browser's language, it won't switch the language. You actually have to logout and kill the session to switch the locale. Bummer.

My main problem with the 2nd phase of the project is choosing whether to "do it right" or "get it done". I often start out just trying to get shit done, but end up being a perfectionist and trying to do it right. This phase took a couple of weeks to get through with WebWork. Ugh - I'd rather just get this stuff done, but I don't think it's gonna happen. I think I'll be working on the "features" phase for quite some time. Oh well, at least I'll learn the ins and outs of each framework.

The final "finishing up" phase is one of the best. It's when everything works and I write the installation scripts and tutorials. This is slightly painful b/c there's nothing new to discover, but it's also nice because there's nothing new to learn or get tripped up on.

AppFuse 1.7 estimated release date? I was hoping for the next couple of weeks, but I'd better stick with the end of the year. I'm sure there's going to be a fair amount of banging my head against the wall in the next few weeks.

AppFuse Gig in San Fran

Todd Huss is looking for an AppFuse developer in San Francisco. More details at http://www.craigslist.org/sfc/eng/49835022.html. For those of you who don't know, AppFuse isn't much of a framework itself - it's more of a directory structure and build file that helps glue Hibernate, Spring and various web frameworks together. You can learn more about it by reading this article on java.net.

The AppFuse Generator

I found the AppFuse Generator project in my comments last night. Richard So seems to have created a nice code-generation tool for AppFuse. It looks like it can create/modify all the files you need to CRUD a database table. I took a brief look at the code and it's all based on Velocity templates, so you should be able to easily tweak things.

This tool does seem to generate the DAOs/Managers - which can lead to more code to maintain. It would be nice if it could be modified to be similar to AppGen where there's a "detailed" version (that generates everything) and a "default" version (which only generates the web tier classes). The default version could use the generic "dao" and "manager" beans. I wonder if this tool supports running/installing the same table more than once? This currently doesn't work too well with AppGen, but shouldn't be too hard to fix.

In reality, I'm pumped that Richard has created this, as well as a project to back it up. I especially like that he's going to try and create an Eclipse Plug-in as part of this project. Nice work Richard!

Studying vs. Doing

My parents are in town for this next week and I expect to relax most of the week, but also squeeze a few hours in each day for Java. I'll probably do a bit of work for clients, but I expect to spend most of my time with Tapestry and JSF. I have to write a chapter that includes these frameworks in 3 weeks and I hope to integrate them into AppFuse by the end of the year.

Last night, I started thinking - I can use this week for 2 things: reading or doing. I could finish reading Tapestry In Action and get a good start on Core JSF. Or I could make the leap and begin implementing them in AppFuse. The latter sounds like more fun. Of course, the books should serve as good reference guides when I need help.

[ANN] DisplayTag 1.0 RC2 Released

Fabrizio, the main man behind the Display Tag, has been fixing bugs and adding features at breakneck speed. Early this morning, he released the final 1.0 candidate for the Display Tag. Good stuff - thanks Fabrizio!

• Download
• Release Notes
• Maven Changes Report
• Demo

Tuesday at ApacheCon

It's now Tuesday morning at ApacheCon and I'm proud to admit I've been pretty lame on the party front so far. It feels great though, I went to bed at 10:30 last night and slept until 9:30 this morning. I pretty much crashed after having such a hectic schedule the last couple of day.

On Saturday night, I was up until 4:00 a.m. cranking out Chapter 10 of Spring Live. I got back up at 7:30 and almost finished it by noon. At 1:00, I arrived at Denver's No Fluff Just Stuff, and moderated a BOF on Comparing Web Frameworks. Then at 2:00, I did a session on AppFuse. Following that, I spent 2 hours finishing up Chapter 10 and sent it off to for editing. 18 pages in 18 hours - oof.

After sending off my chapter, I headed home and had dinner with the family before heading to the airport at 7:00. We arrived in Vegas at 10:30 and went to the Hard Rock for beers. I didn't have any cash so I borrowed some from Jim. After 10 minutes of Blackjack, I was up $120, so I paid Jim back and called it a night. I got heckled as I left the Hard Rock at 3:00 a.m.

Yesterday (Monday), I woke up at 8:30 with a raging hangover. Damn wine chasers - don't seem to work for beer. Bruce didn't take any, got 3 hours of sleep and felt fine. My talk was at 11:00 and I managed to stifle the hangover about 5 minutes before it. The talk went well and the room was packed (approx. 100 folks). After the talk, I grabbed some lunch with Scott, Jim, Jonathan, Howard and his wife.

At 2:00, Dion interviewed me for TheServerSide. At 3:00, I had a meeting with the SourceBeat guys, and had some beers with Michael Koziarski around happy hour. Then I hit an ApacheCon sponsored free-beer thing and later headed to the "Pink Taco" with Jonathan and Dave. I could barely stay awake after dinner, so headed to bed early.

Today, I plan on attending a few sessions and possibly doing some gambling this evening. Sure is nice not having any commitments for the rest of the week. I have a few meetups with folks, but nothing that requires preparation.

Tapestry by Example with Erik Hatcher

It's Saturday morning and I plan on learning more about Tapestry this morning. There's pretty light attendence in the room. Too bad - I bet if it was a JSF talk, the room would be packed. In this talk, we're actually going to build a real application on-the-fly.

Why another web framework?

• HTML should be HTML
• JavaScript Embraced
• Reusable components
• Free developer from dealing with plumbing
  • Request/Response
  • Session/Application Scope
  • URL Mappings (nice, but leads to ugly URLs)
• Event handler driven
• Asset handling
• Line-precise error reporting

Erik says its one of the few frameworks that embraces JavaScript so much. I dig this b/c I think JavaScript is important for web development. Look at what the GMail guys have done with JavaScript. It'd be wicked cool to have this sort of thing open-sourced so we could all create GMail-type interfaces.

Dirty Laundry

• Heavy Duty - can be overkill for small/simple app
• Potentially steep learning curve. More of an un-learning curve. The Servlet API isn't in your face - so all that knowledge is useless.
• Not widely accepted - managers haven't heard of it
• Some awkward conventions (i.e. abstract classes)
  • and some non-intuitive necessary tricks
• Unit testing tough - do you unit test your swing app's listener methods?
  • Tapestry Test Assist should solve this problem
  • Howard's caught the TDD bug, so this should get better
• Lousy URLs - there's a patch on the wiki to fix this
  • Tough to do hit/stat tracking
  J2EE declarative security
• Example applications
  • Workbench and VLib included with Tapestry
  • Better Pet Shop

Workbench Demo - DatePicker component does do i18n (very cool!). Client-side validation does one-field at a time, like WebWork does. I prefer the "all messages in one pop-up" approach that Commons Validator has. Pallete component looks very cool - you can move and re-order items from a multi-select on the left to a multi-select on the right. Chart component looks pretty cool - you can generate graphs very easily. Unfortunately, it's not part of Tapestry, but you can see how to do it in the Workbench app. If you want to see an online version of the workbench, I have it setup on my server.

Repositories for components: Tacos, Tassel, T-Deli and a few mentioned on the wiki.

To bring a component to life, you simply add a "jwcid" to an HTML tag. You can specify initial values for page properties using <property-specification initial-value=""> tag in your template's .page file. The value is implicitly an OGNL expression, and you can define lists using "{'value1', 'value2', 'value3'}". This is great for prototyping before you have a backend or even a page class. To remove elements in a page, specify jwcid="$remove$" on an HTML element and it'll be removed at render time. The restriction is you can't have Tapestry components inside a $remove$ component.

If you don't want to use abstract methods (and hence classes) in your page class, you can use getProperty()/setProperty() methods. However, the recommended way is to use abstract methods.

Templates - two different types. You can put the @component stuff directly into your page - or you can use jwcid's and refer to a name that's defined as a <component> in your page-specification XML file. The Border component can be used to do page decoration like SiteMesh. You can use the Shell component to declare stylesheets/scripts on a per-page basis. This is something I do a fair amount, so it's nice to see it's built into Tapestry.

Internationalization - Resource bundles are component specific (one .properties per page). In a .page, you use <message-binding>. In a template (.html), you use attribute="message:key" or <span key="">. The "key" attribute can't be used on any ol' HTML element, only on the <span> tag. In .java, you use getMessage() and format(). You can also define a custom message source (i.e. read messages from a database). I'm impressed with how easy it is to do i18n in Tapestry. It's also cool that i18n is built-in for templates. Just include a locale extension on your page and it'll be rendered for users with that locale. For example, home_fr.html will show up for users with the French Locale.

Engine - gets all requests. Visit class - POJO that acts as like an HttpSession. You can configure it in the .application file. You can talk to your "Visit" class in a template using "ognl:visit". To call methods on it, just use "ognl:visit.method". Majority of services originate in the Engine. Generally override createXXX methods. Engines can be pooled or created on a per-session basis.

If you override the createXXX methods in Engine, you change the behavior for:

• message source
• global and visit
• property configuration
• template and component sources

contrib:Table - to override use <tr jwcid="columnColumnValue@Block"> - where "column" is the name of the column. Using this, you can easily put links and such into a table cell. Built-in TableModel can be used to talk directly to a JDBC DataSource. The TableModel is smart in that it only brings back the rows it needs to display. Add an exclamation point to the beginning of a column name to turn off sorting for that column. i18n is built-in for headers - the name of the column is simply looked up as a key in the page's .properties file.

Exception handling - Bail out by throwing an ApplicationRuntimeException. This tosses you to the default exception page, which you can override and "pretty up".

Validation - it's robust, but it can only validate <input type="text">. Erik thinks that Tapestry's validation framework could be much simpler and easier to use.

Dynamic Templates - can implement a IDelegateSourceTemplate and pull templates from a database or content-management system. To register your new TemplateDelegate, you can just register an <extension> in the .application file and point it to your class.

Page Lifecycle - initialize(), PageRenderListener(), PageValidateListener(), PageDetachListener(). Can use an ExternalCallback and ICallback to set properties on one page from another. Callbacks look very cool and there's a lot of discussions about them on the mailing list. The VLib app has a fair amount of callback examples.

This was definitely a good Tapestry session - thanks Erik.

XDoclet and JDK 5.0

One of the major issues in XDoclet's JIRA has been the fact that XDoclet doesn't work with JDK 5.0 syntax. After many comments and lots of debate, Anton Adamansky has submitted a patch. If you want to use XDoclet with JDK 5.0 - you might want to give this patch a run for its money. Hopefully we can get it included in XDoclet in the near future.

How do you unit test your Velocity pages?

I've started working with an additional client this morning and one of my first tasks is to figure out the best solution for 1) unit testing the UI and 2) unit testing Velocity templates. It's funny how the blogosphere makes life so much easier. Today was my first meeting with the client and they wanted to know if there was a way to test Velocity templates. Yesterday, I saw a headline in NetNewsWire about unit testing Velocity. I glossed over it b/c I didn't have any use for it. When they mentioned it today - I remembered it, searched on java.blogs and found JUnit Testing Velocity. Folks might think that reading blogs leads to reduced productivity - but I think it leads to more efficient productivity.

I think I'm going to implement something using the JUnit/Velocity stuff above and jWebUnit. jWebUnit will be used to test the WebWork actions and their interaction with the Velocity templates. Anyone had experience (good or bad) using this approach on their projects? Any other alternatives you've used to ensure error-free Velocity pages?

I like jWebUnit because you can easily switch locales and test against ResourceBundle keys for i18n. I don't think this is possible with Canoo's WebTest. The nice thing about Canoo's WebTest is they're migrating to HtmlUnit (rather than HttpUnit), which supposedly has a lot better JavaScript support. Both jWebUnit and WebTest currently use the Rhino js.jar - which throws exceptions for perfectly good JavaScript code.

BTW, anyone know why searching for "appfuse" on JavaBlogs causes a 500 error?

[ANN] AppFuse 1.6.1 Released

This release is primarily a bug fix release, but it also contains a slick "AppGen" tool for generating full CRUD (with sample data and tests) from a POJO. AppGen essentially automates everything you do in the tutorials. I still encourage users to read through and do the tutorials in order to learn the code that is being generated. This feature basically reduces the amount of files you need to create/alter for CRUD from 16 to 2. Better yet, rather than generating the DAO and Manager (as well as the tests), it just uses generic methods in the base implementations. This eliminates the need (and hopefully desire) to create so many DAOs and Managers. In most cases, you can simply use the "manager" bean in your Actions/Controllers and call its respective methods. Thanks to Hibernate for making generic CRUD possible with only a handful of methods. Now you should be able to simply concentrate on the web-tier and only modify/create backend classes when you need special behavior.

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

To upgrade your 1.6 based application, I recommend performing the following steps:

• Download 1.6.1 and extract it to your hard drive.
• If you've renamed your packages, use the Rename Packages Tool to rename packages in 1.6.1.
• Use Beyond Compare (Windows only) to diff the your project against 1.6.1.

This is how I've always done my AppFuse upgrades for Struts-Resume. It takes a couple of hours, but it's a lot easier than me trying to create an upgrade package.

I'll be talking about AppFuse this weekend at Denver's NFJS Conference. Next Monday I'll be in Vegas at ApacheCon. I've never done two different talks back-to-back before, let alone at two different conferences. Should be fun.