Raible Designs

Spring MVC the most popular web framework among AppFuse users

At the beginning of October, I did an informal poll on the AppFuse mailing list to see which web framework users were developing their applications with. Surprisingly, Spring came out on top, and the component frameworks (JSF and Tapestry) are the least used. I find this interesting b/c AppFuse lowers the barriers and reduces the learning curve for all of these frameworks.

If you're an AppFuse user and didn't respond on the mailing list, please leave a comment with the web framework you're using.

On a related note, I noticed that java.net added RSS Feeds for mailing lists today. This means if you have an RSS Reader, you can subscribe to the AppFuse user mailing list.

Heh, I just subscribed and there's no messages in the feed. Maybe this feature needs a little more work.

What's the best way to integrate Ajax into a Java webapp?

I received an e-mail over the weekend asking how to integrating Ajax into into the various web frameworks covered in my Java Web Framework Comparison Whitepaper. Below is my reply:

The best thing that I've seen is to use DWR, Prototype and Scriptaculous.
These will work with all web frameworks, and if you're using Spring on the backend -
DWR makes it easy to expose your beans as JavaScript objects.

Also, there's a number of tag library solutions that greatly simplify things:

  http://javawebparts.sf.net
  http://ajaxanywhere.sf.net
  http://ajaxtags.sf.net

I haven't used the first one, but I have used AjaxAnywhere and saw a demo of
AjaxTags from its developers.  They both look like they could be very useful.

For those of you using Ajax in your Java webapps - what's your advice? Do you use these same libraries or other ones?

This post was partially motivated by my desire to reiterate things that are so obvious.

Open Source CMS Evaluation - Part II: Customization

This is the third and final post in my quest to find the best open source CMS for my needs. Previous posts include Building a website with an Open Source CMS and Open Source CMS Evaluation - Part I: Installation. Based on these two posts, reader feedback, and my installation experience, the final round of candidates include Joomla, Drupal, Magnolia, OpenCms and MeshCMS. These are listed in the order that I expected the final rankings to be - just to let you know what my feelings were going into this final process.

The CMS I choose will be used to build Virtuas's website, as well as customers of Virtuas. By using a CMS to produce websites, the design is separated from the content - and the "adding content" process can be much easier for the customer. This greatly simplifies the "creating a website" process for us, and will likely save our customers a fair amount of design costs. In addition, it makes it much easier for site owner's to maintain the site after it's been published.

As for Virtuas's site, it's static right now, and we'd like to change that. We want to ability to show recent blog posts on the front page, as well as make it easy for Practice Leaders to publish articles. In addition, it should be easy for our designers to change the design (1-2 files) and for our marketing team to add press releases and update existing content. Tomorrow, I'll be presenting my choice to the rest of the team, and we hope to design and start publishing content this week. Our goal is to have a new Virtuas site up and running one week from today.

My goal today was to see how easy each CMS was to customize. In addition, I wanted to see how easy it was to publish an article, as well as to aggregate our latest RSS feed titles onto the homepage. To test the design customizability, I tried to reproduce the current Virtuas homepage. Then I published Jeff's Geronimo Article, and attempted to aggregate feeds from Maria's and Bruce's blogs. My main reason for putting the Java CMS'es lower than the PHP ones in my suspected order of finishing is because I don't they don't have the RSS Aggregation feature.

Rather than just jumping in and using each CMS in anger, I tried to start off by reading the documentation for each. My main focus was on how to customize, but I also looked for an RSS Aggregation feature and ease-of-publishing for articles. I read documentation for 15-20 minutes, then dived into creating a custom theme and adding content. I installed each CMS on my PowerBook, and used Safari and Firefox on OS X, as well as Firefox on Windows XP in some cases.

MeshCMS - I spent 40 minutes looking into MeshCMS before I knew it wasn't the one. The main problem I had with it was the upgrade process. To upgrade to a new version, they recommend that you use symlinks to your files and store them in a separate location on the file system. While this may work for some, it seems a little brittle to me. I'd rather use a solution that keeps everything stored outside of the application by default. Creating a new theme was quite easy - but there didn't seem to be any support for multiple menus (i.e. global and local navigation), nor was there any means to customize the menu template.

I did manage to blow up the whole application at one point, simply because I was missing a JSP tag in my template. Since I had this template selected for the administration as well - it hosed the whole application and spit out stack traces for each page. Luckily, renaming the template directory caused MeshCMS change to revert to the default settings and everything was fixed. The interesting thing about MeshCMS is it looks very similar to the SiteMesh+JSPWiki CMS I wrote a few weeks ago. However, mine allowed full menu creation by editing/creating wiki pages.

OpenCms - When I installed OpenCms a couple of days ago, I initially did it on Windows. Everything worked fine and after waiting 18 minutes for everything to import, I was able to browse and edit the default site. However, today was a different story. The version I installed on my Windows XP box no longer works. When I got to http://localhost:8080/opencms/, I get a directory listing with "resources" and "setup" on it. The same day I installed OpenCms on Windows, I installed it on my PowerBook. It took 38 minutes to complete, but nevertheless, it said the process worked. Today I re-ran the setup and now I have the same result as on my Windows XP box. If the setup and installation is this fragile, I'm not interested. Blame me and the fact that I'm a redneck all you like, but the Magnolia installation is still functioning just fine.

Magnolia - I spent about a half hour with Magnolia before I knew it wasn't for me. While the admin UI is impressive with all it's Ajax goodies, creating a new template is cumbersome and not designer-friendly at all. You have to create a "new node" and then a bunch of "data nodes" under that. The documentation (a QuickStart PDF) is 17 pages long and forgets to mention the "title" data node is needed before the template will show up properly as an option. Once you've created a new template in the admin UI, you have to create the template on your file system - inside the web application. This may make it difficult to upgrade if you're deploying Magnolia as a WAR. The worst part is after creating the template, you have to restart the server. WTF? That seems a bit ridiculous to me. Granted you'll likely be designing your master template in a development environment - but good luck installing Magnolia for a client and having them create a new template.

One of the most interesting things about Magnolia is most of the folks who've recommended it have highlighted that it's "built on the revolutionary Java Content Repository Standard JSR-170". While I can admire the technical merits of this effort, it doesn't necessarily make this a good product. A good product, IMHO, is easy and intuitive to use. The admin interface for Magnolia is not intuitive. I like the fact that I can right-click on a page/node/etc., but on my Mac (with Firefox and Safari), the real context menu shows up on top of the application menu after a second or two. I'm going to pass on Magnolia due to the fact that its not designer friendly, as well as the fact that templates can't be edited in the browser. It looks like something that might be very interesting for developers, but it's simply not friendly for HTML developers.

At this point, it's 10:30 p.m. on Sunday night. I need to make a decision before I go to bed tonight and I'm scheduled to meet with our designer at 7:00 a.m. to start implementing his new design. I haven't started the PHP options, and I've had a couple new ones recommended on my blog while doing this evaluation today. Mal recommended Exponent and Jacob recommended MySource Matrix.

Because I'm down to two choices (and I haven't tried to customize either one), I decided it was worth looking at both of these PHP solutions. Exponent installed easy enough, but MySource Matrix failed miserably. Joomla, Drupal and Exponent all had an easy-to-use web installer that *just worked*. MySource spit out a bunch of permissions errors (even after chmod -R 777 *) and told me I had to run .php files from the command line. Since the other options all installed easily, I decided not to continue evaluating MySource Matrix.

Exponent - I didn't spend very long looking at Exponent. At first, I didn't think it had any documentation b/c it was a bit difficult to find on their site. Maybe it's because they don't have a background set on their site and my browser defaults to gray - making the gray text difficult to read. Even w/o documentation, I was able to navigate around the default Exponent site and figure out how to edit content. It's an easy UI to use, but again I was disappointed to find the "corporate" theme doesn't have a white background. Most good web designers know to set a default background color - and it always annoys me when someone misses this step. It's possible they don't set the background on purpose - like Yahoo does.

The deal-breaker with this CMS was that I couldn't edit any files w/in my browser to change anything (all I wanted was a white background). While it's theme management and templating looks powerful - it's another file-based system where you have to configure everything and then upload it. I agree that this is likely the path that web designers will want to use to get started - but I think it's important that files can be tweaked on-the-fly. Using a good FTP tool is certainly an option, but I'd prefer theme-editing to be part of my CMS. The one thing I did like about this CMS was the clean URLs. Granted, they aren't static-looking by any means, but having a simple ?section=# seems cleaner than the multiple parameters that other systems use.

Drupal - This CMS seems to have a lot of things I want/need as first class citizens. A blog, news feed aggregation and the ability to provide pretty URLs (aliases) for more cryptic CMS-type URLs. I couldn't get the URL aliases to work, but I suspect I was doing something wrong and didn't give it enough attention. I didn't spend a whole lot of time with this CMS, but rather just browsed around the admin interface and read a bit about how to create themes. I installed the PHPTemplate engine, but never installed any themes. When I found out I couldn't edit any of the uploaded templates contents, I started to get discouraged by Drupal. One thing I found disappointing, with both Drupal and Joomla, is they seemed to hard-code my server name into many of their URLs. When I installed these applications on my PowerBook, I used "localhost" for the server name. When testing out things from my Windows box, I couldn't even login to Drupal b/c it kept redirecting me to "localhost". Joomla had a similar problem with localhost, except that it only screwed up stylesheet paths. I was still able to administer the application.

Joomla - My time with Drupal was short-lived, mainly because I was itching to start playing with Joomla - which I've heard a lot of good things about in the past week. Furthermore, it's got a really good-looking administration UI. It's the type of UI that a designer would look at and appreciate. When trying to edit pages from my Windows box - everything worked, but I couldn't save the page. No JavaScript errors or anything, there was simply no reaction. Editing pages and content from my PowerBook solved the problem. I was able to easily create a simple theme that looked like virtuas.com and upload it. The theme isn't perfect, but it was easy enough to create using the Velvet theme from Joomlashack.com as a template. The weird thing about Joomla, at least with the default install, is there's no notion of pages. Everything is some sort of news item. In the pages I created, I was also unable to remove all the authoring notation and other junk that I don't want to show. The admin UI had options to remove the stuff, but even after "applying" the changes, they still showed up in the reader view.

It's now 1:30 a.m. on Monday morning and the last three CMS's definitely didn't get the attention they deserved. Nevertheless, I think they're the best of the bunch. Not only were they much easier (and quicker) to install than the Java options, but their UIs are also good-looking and easy to use. Drupal and Joomla both seem like excellent choices. Drupal seems to be more of what I'm looking for since it has all the features I want, and allows aliasing of URLs to make it appear like a static site. However, Joomla is a lot more eye-catching and that alone makes me want to use it. Neither of these CMS'es seem to have a full-featured blogging engine, at least not one that's as good as Roller.

Conclusion: I'm going to recommend we use Joomla, and look into doing some URL Rewriting to pretty up it's URLs. I doubt there's a whole lot we can do, but I'd like to figure out a way to make them a bit more search engine friendly. Drupal seems like an excellent choice as well, but the fact that I can't edit templates from the UI kinda sucks.

Thanks for listening y'all - all your comments and feedback during this evaluation have been great.

Hibernate Relationships with XDoclet Tutorial

I finally got around to finishing the Hibernate Relationships tutorial for AppFuse today. This initial version includes a howto for creating the UI with Struts. In the future, I'll add sections for creating the UI with Spring MVC, WebWork, Tapestry and JSF. Those should be easy now that the hard part is done. This is a first cut at this tutorial, so it's likely there's issues, bugs and things I did wrong.

Now it's your turn. If you have a chance, please try it out and let us know how we can improve it.

Should I change AppFuse's default web framework?

Currently, the default web framework in AppFuse is Struts. It's nothing fancy like Shale or Struts Ti, but rather Struts Classic. Even though Struts is not dead it's a pain in the ass to work with compared to other MVC frameworks like Spring MVC and WebWork. Yesterday, on the AppFuse Mailing List, I kicked off an informal poll about switching to a different default web framework. I think most of the people that choose Struts w/ AppFuse are choosing it b/c it's the default. Making another framework the default would likely same quite a few users a lot of headaches.

So which one should I make the default? Here's my thoughts from the mailing list thread:

I like Spring MVC and WebWork better than Struts, but I believe that WebWork is much easier to understand and develop with. Unfortunately, it's not well documented or marketed, so it's a bit difficult when you run into snags. Of course, if you contact the user community via forums or e-mail, answers flow quickly.
...
I'd like to use the framework that's simplest to understand. Right now, in my eyes, that's WebWork. I think JSF and Tapestry are excellent too (as component-based frameworks), but Tapestry's learning curve is difficult and JSF has a lot of issues (like everything is a post). Hopefully things will get better with JSF 1.2, but it's probably another 6 months before MyFaces supports 1.2 - let alone the app servers.
...
Maybe we should just drop Struts altogether - or replace it with Struts Ti? Unfortunately, it'll probably be a while before it's ready for production (I doubt it's that useable now).

Of course, if a WebWork Book was out - this move would be a lot easier. I did talk to Patrick Lightbody on IM yesterday and he said "it's done" and supposedly he has copies, but I haven't seen anything on the WebWork Blog to prove this.

A related question: how much would it hurt AppFuse if I dropped Struts altogether and went with something like Wicket instead? I'd like to keep that cap at 5 web frameworks. If I dropped Struts and added Wicket, I might lose potential users, which might not be a bad thing.

Biled Again, this time because my design sucks

Looks like I've been biled again. Unlike the last time, this time Hani doesn't offer any specifics, he merely says that my OSS efforts don't do anything other than the "very very basics".

Java, specifically, goes a long way towards ramming down a set of design principles. Said principles are followed fairly blindly by most practitioners. The OSS world is awash with examples of people who have read the right books, but have absolutely no skill or talent at conceptualising or grokking the underlying principles behind the books. To them, the design pattern is an end goal, not a tool. To pick one example (out of thousands), look at Matt Raible's OSS efforts. It has inheritance! It uses PATTERNS! It is LIGHTWEIGHT! Yet, I'd argue that it's very badly designed (if you don't believe me, just try getting it to do anything other than the very very basics.)

I'm assuming that Hani is speaking about AppFuse and Equinox, because my other efforts in OSS are minimal (Roller, Display Tag, XDoclet and Struts Menu). The reason I'm writing this post is because I'm curious to know what Hani tried to do that didn't work? Was it AppFuse/Equinox that failed? Or was it the underlying framework? Did he try to do indexed properties with WebWork or modify build.xml to deploy to Orion? Is the feature he's looking for something we can fix?

As a defense of my use of patterns, lightweight containers, etc. - it's not so much my doing that these happen to exist - they're more of a reflection on what user's want. It's a problem with Java developers in general - if you're not using patterns - users want to know why. Furthermore, most of the J2EE patterns in AppFuse are from the underlying frameworks, not from anything that I did.

As far as the design of AppFuse, I agree it could use some work. There's a lot of stuff in AppFuse that I don't use - so when I start a project with it - I usually rip out about 20-30% percent of it's features b/c I won't use them. Unfortunately, it's not that easy for others to do this b/c they don't know what they'll break if they remove a bunch of stuff. I'd like to move to a more modular, plug-in type architecture - but I have a feeling that that's the path to over-engineering. Even so, it would be pretty cool if it was possible to turn on/off features (even the use of a particular web framework) by changing a properties file.

Building a website with an Open Source CMS

I think the open source community has done an excellent job of figuring out how to create frameworks for developing web applications. But what about websites. You know, the web presence that every company wants - for minimal cost. For most companies, it's nothing more than 5-10 pages that tells a bit about the company, show some management folks and tells you how to get to their offices.

I've developed many websites over the years, many that were static, but more that were dynamic. The unfortunate thing about all of them is they required someone technical to update them. Often, the client had to contact me if they wanted anything new on the site. I've often thought there was a better solution - and I think I'm at a point where I know what customers want, and I know how to provide it. The solution is a Content Management Solution (CMS). One of the biggest problems with static websites is they're not dynamic enough. A CMS can alleviate this problem by reducing the bottleneck that a traditional "webmaster" creates.

In my mind, there are a couple of things that make a good CMS: 1) it's open source (to minimize costs to the client) and 2) it's easy to customize. On the customization front, my demands are a bit more rigorous - mainly because I know what many folks want in a website. Here are my main criteria for a good open source CMS - when it's used to power a regular ol' client-updateable website:

• Design customization: I should be able to customize all the (X)HTML that's generated using one or two files (like SiteMesh allows). It should be possible to change the look and feel of *everything* by modifying some CSS. It should also be possible to use Mike Stenhouse's CSS Framework to simplify layout choices for clients. Ideally, a web designer or regular ol' HTML person could do the customization.
• Static-looking URLs: The site should look like a static site. The URLs should be all lowercase and end with .html. It should be possible to modify all the URLs to look as if all pages are static. Apache's mod_rewrite and the URL Rewrite Filter are great tools for making this happen, but it'd be nice if the administration of the application allowed for setting these rules.
• It shouldn't look like a CMS: No login links, no registration links, etc.
• Ability to easily add dynamic content: It should be easy to add dynamic content - such as RSS Feed headlines to pages.
• Menu Customization: In the application, it should be possible to create menus (both main and local navigation) and configure a page to highlight a menu when a particular page is shown.
• Versioning of pages: In case someone messes something up, it should be easy enough to revert back to a previous version.
• Easy to use: It should be possible to train a marketing person (with little technical knowledge) how to use the system in 10-15 minutes.

For technical companies (such as Virtuas), there are a few additional requirements I'd like to see:

• Articles with syntax highlighting: It should be easy to publish articles with code that's colorized. The Java2HtmlPlugin for JSPWiki is a good example of this. I currently don't know of any for XHTML, XML or scripting languages like Ruby or Python.
• File Upload: For uploading white papers and other technical publications.

So I've started looking at open source CMS's that fill my requirements. Last weekend, I wrote a solution that fills all of these requirements using SiteMesh, JSPWiki, CSS Framework, Acegi Security and the URL Rewrite Filter. It only took me about 6 hours to complete, but after completing it - I started wondering if I really wanted to start another open source project and maintain it. The answer is no, I don't want to create something new - I want to use something that's already out there. However, since I do have something that satisfies all my requirements, I will use it if I can't tweak an existing OS CMS enough.

Here are a list of CMS's that I'll be looking at in the next week or so. If you're associated with any of these projects, please leave a comment and let me know how many of my requirements you satisfy.

• Daisy
• Magnolia
• Bricolage
• phpWebsite
• Mambo/Joomla

I'm a bit hesitant on Daisy b/c it requires XSLT knowledge for design customization. Magnolia has long URLs and doesn't appear like a static site - and the PHP ones often have .php in their URLs. It should be an interesting investigation to see if these (seemingly) heavyweight solutions can solve a few simple requirements.

Stripes

Greg Hinkle writes about a new JDK 5-only Java web framework called Stripes.

Stripes is a presentation framework for building web applications using the latest Java technologies. The main driver behind Stripes is that web application development in Java is just too much work! It seems like every existing framework requires gobs of configuration. Struts is pretty feature-light and has some serious architectural issues. Others, like WebWork 2 and Spring-MVC are much better, but still require a lot of configuration, and seem to require you to learn a whole new language just to get started.

I dig the fact that someone is trying to create a web framework that requires less configuration. It's also very cool that they've released it as 1.0 (rather than 0.1 as many OS projects do) and it also seems to be well documented. Unfortunately, it doesn't look like there's any support for Spring or dependency injection.

Personally, I don't mind the configuration required by WebWork or Spring MVC - but then again, I use AppFuse and tend to generate most of the configuration code using AppGen. Even so, it would be nice to get away from the configuration requirement. Hopefully more framework authors will find ways to reduce or even eliminate the XML hell we have in Java web frameworks. Kudos to the Tapestry developers for doing this in their 4.0 release.

I like the convention over configuration that Rails uses. It's this same mantra that I've been trying to develop AppFuse with for the past few years. The problem with Java web frameworks is developers want configuration choices - even if they never bother to use them.

Wicket is the most widely used Java Web Framework

According to this post, Wicket is the most widely used Java web framework. While I believe his statements are true, IMO it's only true in the context of this guy's post. My guess is that most of the folks that read his post were Wicket users, or somehow the Wicket Team got wind of this and told users to e-mail this guy. The main reason I don't believe that Wicket is the most popular is because it's so new. I do think it's an up and coming framework that may become the most popular, but I don't think it's there yet.

So, to answer this question, I believe that claiming Wicket to be the most widely is Just Good Guerilla PR. To put some numbers behind that, here's some graphs showing mailing list traffic for the various Java web frameworks.

Granted, these are just indicators of the number of users - but I believe they are a good indicator. One interesting note about these stats is that Wicket's mailing list traffic has increased significantly in the past few months. Ironically, here's what one of the Wicket developers had to say about this statistic about a month ago:

... who says having a lists that has a lot of traffic is a good thing? It might just as well be an indication of a too-hard-to-understand framework having insufficient documention.

In the past couple of months, I've spoke in front of 25+ Java developers on 4 different occasions to talk about web frameworks. I've asked those developers which frameworks they've used, or plan on using. Struts is still the most widely used, with WebWork and Tapestry the least used. Surprisingly, JSF seemed to be getting no traction among the the audiences I spoke to. Even more surprising (to me at least) was that the most popular web framework continues to be the in-house framework. The overwhelming majority of the developers I've talked to aren't even using open-source web frameworks.

Equinox on Resin 3.0.14

Yesterday I moved demo.raibledesigns.com from Kattare to Contegix. The main reason I moved is because Contegix is much more responsive when I have issues, as well as Kattare's server was incredibly slow to startup Tomcat. The move went pretty smoothly, but I did run into a couple issues - caused by moving from Tomcat 5.0.28 to Resin 3.0.14. The issues were only in one application - the MyFaces version of Equinox.

The first issue was that the corejsf-validator.jar that I'm using (for client-side validation) contained an invalid TLD file. It was easy enough to fix as it was missing a <short-name> element. This is the 2nd issue I've found with this library - obtained from David Geary's Core JSF book. The first issue is that Spring's Ant-style patch matching doesn't work when this JAR is in the classpath. Anyone out there using a better (less buggy) library for client-side validation in JSF?

The 2nd issue was that MyFaces depends on commons-el.jar, which is shipped with Tomcat. Not so with Resin. Adding this JAR to my WEB-INF/lib directory solved the problem. I've committed both changes to CVS.

Below is a full listing of the sample apps I have installed on this server. The one app that I didn't move is Struts Resume. I'll be moving that one to appfuse.org today.

• Data Grid Tag
• Equinox (Spring+Hibernate)
• Equinox (MyFaces + Hibernate)
• Equinox (Struts + Hibernate)
• Equinox (Tapestry + Hibernate)
• Equinox (WebWork + Hibernate)
• MyUsers
• Struts Menu
• Tapestry's Workbench
• WW2 Tutorial

I'm open to adding more, so let me know if you have one you'd like hosted. Of course, I reserve the right to refuse suggestions based on my interest in the functionality they're demonstrating.