Raible Designs

Integrating Compass with AppFuse and the Display Tag

ChenRanHow has written up a detailed tutorial on how to integrate Compass with AppFuse and the Display Tag. From his mailing list post:

• Part 0. Overview of the practice
• Part 1. Setup env, add Compass and related library to AppFuse
• Part 2. Create ant tasks for create and delete index
• Part 3. Use annotation to make Compass resource mapping
• Part 4. Create Struts action to perform search
• Part 5. Make DisplayTag work with Compass

Thanks ChenRanHow!

Another great tutorial was recently written by Luciano Fiandesio. If you're looking to use Quartz, checkout Luciano's (well styled) AppFuse and Quartz tutorial.

In other AppFuse news, FanYang has started translating the documentation to Japanese, Mike McMahon has converted the appfuse-hibernate module to annotations, CruiseControl is continually testing, Mike Horwitz has solved most of the "Maven doesn't read a WARs dependencies" issue, and Scott Ryan is still hard at work on the code generation plugin. Even better - we've asked Scott to come aboard as a committer and he's accepted. Welcome aboard Scott - we appreciate all the work you're doing.

As far as progress on AppFuse 2.0, we're almost done with the Maven 2 conversion. The only thing left is figuring out how to get Mike's maven-warpath-plugin to hook into the Eclipse and IDEA plugins to they generate project files correctly. After that, it's time to start on documentation. I'm still torn on if we should use Confluence or DocBook. However, after looking at Spring's documentation for the past week, I think DocBook is probably the better choice. Then again, Stripes' Confluence Wiki looks nice and organized.

What do you think? What's the best way to write documentation for an open source project? Which system do you prefer to read? From experience, I prefer reading Spring's documentation over trying to find stuff in WebWork's wiki.

We've had great success with AppFuse users contributing to the documentation via a wiki, and I'd hate to create a documentation system that gets away from that. Maybe a DocBook/Confluence combination is the way to go? It looks like the CeltiXFire folks are having a similar debate.

7 simple reasons to use AppFuse

IBM developerWorks published my "Seven simple reasons to use AppFuse" article today. Here's a summary:

Getting started with open source tools for the Java™ platform such as Spring, Hibernate, or MySQL can be difficult. Throw in Ant or Maven, a little Ajax with DWR, and a Web framework -- say, JSF -- and you're up to your eyeballs just trying to configure your application. AppFuse removes the pain of integrating open source projects. It also makes testing a first-class citizen, allows you to generate your entire UI from database tables, and supports Web services with XFire. Furthermore, AppFuse's community is healthy and happy -- and one of the few places where users of different Web frameworks actually get along.

While you're there, you might be interested in reading the "Introduction to Spring 2 and JPA" tutorial. I don't know if we'll get JPA support into AppFuse 2.0, but it's certainly a possibility.

As far as AppFuse 2.0, here's the current structure I've started on for Maven 2:

appfuse
    - data
        - hibernate
        - ibatis
    - service
        - pom.xml
        - src
    - web
        - jsf
        - spring
        - struts
        - tapestry

After code is moved into the directory structure above (or completely re-written), I'd like to move to working on creating single module archetypes and multi-project archetypes (data, service, web) with Maven 2.

After getting the Maven 2 structure checked in, hopefully we can start looking at replacing AppGen. Scott Ryan has done a fair amount of work on this so far with his AppFuse Maven Plugin.

I plan on documenting the plan of attack and milestone features for 2.0 sometime this week.

Update: I started working on the Maven 2 conversion last night. The above structure has changed slightly. Now there's a project in data and web (notice the pom.xml and src in these directories). These projects will contain the classes/files that are common to their sub-projects. The fact that these projects even exist will likely be transparent to the end user.

Dream Machine

Well done Apple, you've created my dream machine. Too bad it's so damn expensive. My ideal configuration is as follows:

• Two 3GHz Dual-Core Intel Xeon
• 4GB (4 x 1GB)
• Hard Drive - Bay 1: 250GB 7200-rpm Serial ATA 3Gb/s
• Hard Drive - Bay 2: 500GB 7200-rpm Serial ATA 3Gb/s
• 2 x NVIDIA GeForce 7300 GT 256MB
• Apple Cinema HD Display (23" flat panel)
• 2 x SuperDrives
• Both Bluetooth 2.0+EDR and AirPort Extreme
• Apple Wireless Keyboard and Apple wireless Mighty Mouse
• AppleCare
• Subtotal: $6,436.00

The nice thing about owning one of these bad boys is you could run several copies of Linux and Windows (using VMWare and/or Parallels). I could literally buy one machine and have 5 in a matter of hours. Hmmm, I should probably bump up that ram to 8GB.

It's tempting, but that's a lot of cash to shell out for a machine. Then again, the more write-offs the better.

Fun in DC

I made it back to Denver yesterday after quite a week in DC. The trip had to be the most fun I've ever had on a business trip. This was mostly due to my partners in crime, James Goodwill and Bryan Noll. Not only are these guys kick-ass Java developers, but they keep you entertained all day long. With my bad back, the ridiculous rain, and getting lost all the time in our rental car, we had quite a trip. The tech meetup on Wednesday night at Brickskeller was awesome. Thanks to all the guys that showed up - we'll definitely do it again in July.

Next week, we're working remotely, then we're back in DC on the 10th. Wednesday, July 12th looks like a good date for the next Tech Meetup. We're open to venue suggestions, but we're also more than willing to return to Brickskeller.

RE: What Web Application framework should you use?

Tim O'Brien has an interesting post titled What Web Application framework should you use?. The first thing I noticed about this post is the permalink. It looks like he started with "Isn't Rails supposed to change...", which makes me wonder what the rest of the title was. In this post, he rags on Java Web Frameworks and the lack of a clear path for choosing one. He ends up predicting that many will stick with Struts 1.x (poor bastards) and those that aren't tied to Java should move to Rails. I don't have a problem with folks moving to Rails, but I would like to comment on the Java Web Framework space and Tim's comments.

He says:

Prediction: The confusion over what is happening over at Struts is going to discourage people from continuing to use it. The Struts team did the right thing in recognizing that Struts 1.x was a dead-end, but that project needs a single public message. Is it Struts Action or is it Struts Faces? Or is it two frameworks capitalizing on the Struts brand name?

I think what is going on in the Struts project is definitely two frameworks capitalizing on a brand name. That was a concious choice on the project's part when they chose to start creating sub-projects. The interesting thing about Struts Shale is it's largely a prototype for JSF 2.0. Furthermore, it was rejected by many Struts developers as becoming Struts 2.0. Why? Because JSF sucks. Especially when used with JSP - which is what most folks are doing.

JSF continues to be the most over-hyped under-used framework in Javaland. If you read the blogs of first-time users, you'll find many complaints and issues on how things work. Granted, most of these problems are with JSP and the implementation, but still. If I were in charge of JSF, I'd dump JSP altogether, bundle Facelets with it and allow more flexible page navigation (including controller-to-page). Don't get me wrong, I like the ideas behind JSF, I just don't like the implementation (or the fact I have to wait years for things to be fixed in the spec).

That being said, I've yet to meet an unhappy WebWork fan. If you find someone that still likes Struts, ask them if they've used WebWork. Chances are they'll say no. As far as Tapestry is concerned, the learning curve is too high. It's been rejected time and time again by my clients because of the learning curve. Are they going to fix this? Yep, they're going to re-write the whole damn thing - again! Every major point release of Tapestry throws backwards-compatibility out the window. Furthermore, I've heard once you get over the learning curve, it's a joy to work with. I've also met people at conferences that've used it over a year and say they're still struggling with its concepts.

Spring MVC - I wish I had bad things to say about it, but I don't. It (obviously) has the best Spring integration, but I've found WebWork much more pleasurable to work with. Sure, Spring has a ThrowawayController, but with a name like that, you can tell it's a second-class citizen.

Inspired by Tim's post, here's my prediction:

Struts Action 2 will be the best choice for developing Java-based web frameworks. Not only does it support JSF, but it's easy to learn, test and use. Furthermore, it seems to be the most often used framework in major software products and web sites.

How's that for a clear message? Struts Action 2 is the shiznit, now let's get back to developing applications.

Disclaimer: This is my opinion with a lot of stuff thrown in to get folks riled up. I've never put a JSF, Tapestry or Spring MVC application into production (except for AppFuse of course), so most of my opinions are likely without foundation. In wonder how many applications Mr. O'Brien has put into production with these frameworks?

Ajax on Rails with Stuart Halloway

There's a number of presentations I'd like to attend during this time slot. In particular, I'd like to attend Testing with Selenium and Simplified Ajax Development in Java with ICEfaces. However, Stuart Halloway is an excellent speaker and I'd rather hear him talk than learn something in another session. Hopefully other attendees blog about the aforementioned sessions so I can still learn something from them.

Agenda: Ajax, Libraries for Ajax (i.e. Prototype and Scriptaculous), Rails and Ruby.

There's probably 100 people in the room. Stuart did a survey of who is using Rails - I'd say the response was about 10%. He also asked who's considering it for future development. The response seemed to be around 25%. I'm sitting in the front of the room, so I probably didn't see the results as well as Stuart did. Regardless, it's interesting to see that most people in the room won't be using Rails, they're merely interested in it (or they wouldn't be in the room, right?).

The best way to play with Rails on Windows is called InstantRails. For OS X, there's Locomotive.

All the demos given during this session are available in the ajax_labs section at codecite.com.

Things we're going to look at: autocomplete, in-place Editing, searching, sorting, expando, drag and drop, sort, server-side validation, client-side validation, and prototype windows (Stuart prefers to call them divdows).

Stuart is talking a lot about how Rails works at this point, model objects, yml files, tests and sample data. One of the things that I find interesting about most CRUD-generation frameworks is they don't take tests into account. Ruby on Rails generates tests, so does AppFuse. If you work on a CRUD-generation project for web development, do you generate tests too? If not, don't be embarrassed, tell us. There has to be a good reason you're not doing this.

Now the audience is struggling with the concepts in Rails, how ActiveRecord works, etc. For example, one guy asked if it's possible to use JDBC with Rails. It's definitely a humorous question, but Stuart handled it quite well without ridiculing the guy. A couple of notes: Rails doesn't work well with stored procedures or composite keys.

Now we're looking at the view layer, in particular a show.rhtml template. It's pretty simple , but not very HTML-ish. Looks a lot like scriplets in JSPs. Autocomplete with Rails is mostly CSS-driven. To use it in a Rails view, you start with the following line of code at the top of your template.

<%= stylesheet_link_tag 'autocomplete' %>

In Rails, when you want to render an Ajax response in a controller, you use the following at the end of your method.

render :layout=>false

This turns off any page decoration. It'd be nice to have something like this in the Java world - so you could turn off page decoration from SiteMesh, Tiles, etc. It shouldn't be hard to implement this in SiteMesh, but it might take a bit of work for Tiles.

Partials are Rails' way of creating fragments that are designed to be populated and returned by Ajax calls. Their naming convention is to being the filenames with an underscore. For example <%= render :partial=>'search' %> looks for a _search.rhtml template.

For Ajax development with Rails, you're not tied to using Prototype or Scriptaculous. However, since Rails has helper methods that emit the JavaScript, it makes things much easier. If you'd like to use Dojo, you'd have to hand-code the JavaScript into your RHTML templates, or write helper methods for Dojo. Stuart would like to see a Rails plugin that allows you to switch the Ajax helpers from one library to the other.

The last thing Stuart showed was Prototype Windows. This looks similar to lightbox gone wild, except you get better styling around the modal window. If you haven't heard enough of what Stuart has to say, checkout blogs.relevancellc.com. One of the most interesting things lately is he's been posting reviews of the various Ajax books.

Ajax and Open Laszlo with Max Carlson

Max is the co-founder and Lean Runtime Architect for Laszlo Systems. Max doesn't look at all like I pictured him (do they ever?!). He looks like a heavy-duty engineer, long curly hair, a little rough around the edges. I respect him more already. ;-)

Laszlo Systems Background: company founded in 2000. Laszlo Presentation Server (LPS) released in 2002. Embraced open source; LPS became OpenLaszlo. 2005: it's been widely adopted (130,000 downloads to date). This year, they're extending OpenLaszlo to support multiple runtimes, including DHTML. The company makes money of training and support, as well as developing custom applications (i.e. Laszlo Mail) and modules.

On 2/1/2006, Laszlo Systems joined a select group of tech leaders in establishing the Open Ajax community. Jointly committed to "making it easier for an open source community to form and popularize Ajax."

Demo's: Laszlo Mail, Pandora, Barclay's and Gliffy.

Developing with OpenLaszlo: XML-based, use your favorite XML editor. It's source-control friendly and has a library mechanism (for modularization). It's a familiar methodology for software engineers. It has standard OOP features: attributes and methods, class definitions with inheritance, familiar design patterns apply. There's an emphasis on declarative constructs. Finally, there's an open source Eclipse-based IDE4Laszlo. Originally developed by IBM, among the most popular downloads on alphaWorks. It now contains a WYSIWYG tool and is hosted at http://eclipse.org/laszlo.

LZX: Laszlo's XML Application Description Language: Flash independent tags and APIs (no ActionScript, movieClips, etc.; no need for Flash development). This allowed them to easily port to a different runtime. With OpenLaszlo, you can interface with your server via XML over HTTP, SOAP, XML-RPC and Java RPC. It has a runtime constraint system, hierarchical data binding with XPath. It has media, streaming support (although the Flash runtime seems to load images real slow - see the DHTML vs. Flash demo on http://openlaszlo.org).

Now Max is going through the Laszlo in Ten Minutes tutorial. If you haven't seen this, you should definitely check it out. It's a good quick introduction to OpenLaszlo. One of the unique features of OpenLaszlo is its components are written in LXZ. Compare this to XUL (components written in C) and Flex (components written in Flash) and it seems a lot more open.

In order to solve the nested-for-loops problem with JavaScript and DOM-manipulation, OpenLaszlo uses XPath and turns for loops into simple URL-like expressions. For example:

<text datapath="dset:/employee/firstName/text()"/>

Noticed on Max's Firefox toolbar: a del.iciou.us menu.

For the last 1/2 hour, Max has been talking about LZX, how to handle events, etc. In other words, since I've already worked with OpenLaszlo a bit, I haven't learned anything new.

Now Max is talking about OOP and how you can declare classes with certain attributes and then re-use them. It's kinda like Spring's "abstract beans" where you can declare a template bean and override attributes in child beans. In addition to allowing classes to be declared with no parent, you can create classes that extend an existing class. A common usage is declaring default values and then overriding visual elements (i.e. border size, colors, etc.).

OpenLaszlo 4.0 (with Ajax support) is targeted for a release by the end of the year.

Personally, I think OpenLaszlo is a very cool technology. However, it definitely needs a better IDE IMO. The last time I tried IDE4Laszlo on my Mac, it wasn't even close to useable. From a development perspective, using OpenLaszlo was difficult to work with because I felt like such a moron. With HTML and CSS, I know how to program UIs and it's difficult to give up that knowledge and rely on something else to provide the look and feel of my UI. In reality, I'm simply frustrated with my OpenLaszlo skills and would likely feel different if I was paid to develop a real-world application with it. After all, getting paid to work with a particular technology is almost always the best way to learn it.

Max is a great speaker and did a good job of introducing OpenLaszlo. Furthermore, this was one of the most interactive sessions I've seen at this conference. There's definitely a lot of folks interested in this technology.

Lessons learned building a 130+KLOC JavaScript application by Scott Dietzen, CTO of Zimbra

Scott Dietzen is the former CTO of BEA. Apparently he was one of the original founders of WebLogic, before it was bought by BEA. Scott's hope tonight is to share his experiences from developing Zimbra. Why does Zimbra use JavaScript and Ajax?

• Richly interactive UI
• Rich client/server communications
• Zero-cost administration
• Web security
• Web look and feel (back button and bookmarks)
• Multi-browser "standard"

All of the above features where things the Zimbra team expected. They also got lucky in a number of areas.

• SAO/Mash-ups and Ajax authoring
• RIA winner? Big sites voting with their feet: Google, Microsoft, Yahoo, Amazon, etc.
• It really works

They started building Zimbra 2.5 years ago, long before Ajax was possible. Scott actually tried to talk his team out of using JavaScript when they first started architecting the application.

Zimbra's tools are good for Java programmers. If you're not familiar with OO concepts, it might be a bit difficult to understand. Now Scott is showing some demos, basically grids and trees - all built using the "Zimbra toolkit", whatever that is. Now he's moved on to demoing the Zimbra application itself. I used Zimbra as my primary e-mail client for a couple weeks and it's by far the best web application I've ever used. Not only does it look awesome, but everything works just as it would in a desktop application. The unfortunate thing about Zimbra is it has two licenses: an open source one and a pay-for version that has all the features you really want.

Zimbra = "Pure" Ajax. All UI behavior specified in JavaScript. The *entire* UI is written in JavaScript, no HTML. It's more like a typical GUI application from a programming perspective (think JavaScript SWT). Result is "husky" client 3-tier architecture. All UI on client, server-side Java code for UI operations. This is very different from HTML "design center" where you start with an HTML page and augmenting with Ajax. The Zimbra toolkit actually doesn't fit very well into most applications, where folks enhance HTML pages. It's more designed for programmers who want to write their entire application in JavaScript.

Ajax is finally giving us a clear partition between client logic and server logic. The dividing line is up to the developer, that's the challenge for web developers today. It's basically a user-defined SOA Endpoint. Before Ajax, in the Java world, JSPs and Servlets were considered the client-side, even though they were really more server-oriented.

Ajax applications are cheaper on the server/network than Web 1.0/HTML apps. Modulo the initial download (gzip is essential). Ajax is much more expensive on the client CPU. Tend to be finder grained in their client/server interactions. They tend to be more stateful. Rule #1: Pick your service bindings well! For modularity and re-use/mashups.

"There's a special place in heaven for whoever had the patience to get all of that JavaScript right." - Paul Ambrose, WebLogic Founder on Zimbra

Ajax Challenges: Browsers and Toolkits. Browsers render the same HTML differently, they have different event models, different levels of DOM supported, they have different APIs that do the same thing, as well as many issues. As far as toolkits for Ajax, there's too many rather than too few. Consolidation would definitely be a good thing.

Zimbra's Ajax Tookit (AjaxTK), Apache Kabuki* is modeled after SWT. It's a JavaScript OO class library and open source (Mozilla or Apache licensed).

Another big challenge is lack of integrated tooling. There's lot of technologies to deal with concurrently: HTML, CSS, JavaScript, etc. The initial stab at a solution is the Open Ajax Initiative. This is largely a set of technologies from Eclipse, Mozilla and Apache. There's 30-odd companies involved with the initiative, including: IBM, Zimbra, Eclipse, Firefox, Apache, Google, Yahoo, Oracle and Red Hat (or at least that's the logos Scott has on his slides).

The proprietary Ajax Landscape consists of MS Visual Studio (Tooling) and MS Atlas (Toolkit). On the open source side, there's Eclipse+Mozilla for tooling and all kinds of frameworks for toolkits (i.e. Zimbra/Kabuki, Dojo, Scriptaculous). Scott's opinion is there's really no room for any proprietary vendors to provide solutions outside of Microsoft.

Now Scott is doing a demo of mash-ups in Zimbra. He's showing how you can mouse-over many things in an e-mail message to get the information you're looking for w/o switching to a new page/context. Mash-ups he showed include: real-time flight information, displaying schedule for a particular day, dragging a message to an SMS sender, viewing a map by mousing over an address. The latest thing they're working on is dragging an appointment from a calendar to a "travel agent" that books your flight.

Zimbra also includes a WYSIWYG authoring environment for documents. It allows you to do HTML editing (in design view) as well as embedding spreadsheets within pages.

Zimlets: extensible mash-ups for e-mail, calendaring, IM, etc. They're a merge of "pull" and "push". There's zero-client install and they're secure because they're managed by the server administrator. To create a Zimlet, you develop a declarative XML template (Regex, ActionURL, XSLT, CSS, Menu). JavaScript can be used to override Zimbra client-based classes. JSPs can be used on the server-side for customization. Ajax Linking and Embedding (ALE) is Ajax components that are embeddable in editable HTML (simple docs, spreadsheets, etc.). Views are read-only HTML and WYSIWYG Ajax authoring (Ajax cod is the "authoring" application).

Practical Tips for Ajax:

• Use an Ajax toolkit
• CSS is your friend
• Use JSON (as well as XML)
• Use asynchronous network programming
• MVC paradigm worked for us
• Tooling better, but rough edges remain
• _all.js -> jsmin (saves ~ 1/4X)
• _all.js, _all.css -> gzip (saves ~ 3-4X)
• Mercury's QuickTest-Pro (QTP) [IE + FF*]
• Pick your fights - not all applications need to be Ajax enabled
• No such thing as secure client-side business logic in Ajax
• Dedicate some top UI OO talent (or wait for tech to catch up)

Ajax Sweet Spots:

• Richly interactive UI desirable (HTML simplicity is ideal for many applications - for example, you'd rather use Amazon's one-click than drag a book to a shopping cart)
• Combine with web look and feel and deployment
• No client-side data/resources (but is changing, stay tuned)
• Perfect for on-demand services

Recipe for Ajax Success: Ajax is not a business model, compelling and appropriate innovation is essential.

Next Ajax Steps: In open source land, try the OSS toolkits, Eclipse ATF and participate in Ajax communities (Apache/Zimbra, Eclipse, Mozilla, Dojo, Scriptaculous). Scott moved to fast for me to catch his recommendations for Microsoft developers. He did have positive things to say about Microsoft though.

Hardest Ajax problem of all? Recruiting. According to Scott, it's incredibly hard to recruit people that know Ajax.

Update: Additional coverage of this talk is available at Ajaxian.com.

What happened to Middlegen?

In AppGen (AppFuse's code generator), I recently integrated support for generating CRUD code (and tests!) from database tables thanks to APF-95 from Bobby Diaz. Previously, it was only possible to generate code from POJOs, but now both are supported. The "mapping files from tables" is done using Middlegen.

Unfortunately, Middlegen seems to be a dead project, especially since its main web site is missing (fixed!). I'd love to use another project that generates XDoclet tags in hbm.xml files, but I don't believe there is one. AFAIK, the Hibernate Tools project does not support XDoclet with its tools. Anyone know where the Middlegen documentation is located? All the documentation used to be on their site.

The good news is the solution I have works, and it works well. However, I definitely look forward to re-writing AppGen. XDoclet as a templating language sucks, and reading XDoclet tags to determine how to generate the UI seems pretty hackish. Hopefully we can use APT and FreeMarker (or Velocity) to process annotations and spit out code in a future release.

Update: The Middlegen website was lost, due some heavy server upgrades. The problem has been fixed and it's back up and running. Now I don't feel so bad about using Middlegen since the project appears to be alive and well.

gotAPI.com - an API Lookup Service

A friend just IM'ed me a link to gotAPI.com. This is a very cool site that allows you to lookup API information on practically everything I use: HTML, CSS, Java, Spring, Ant. Definitely a good bookmark to have.