Raible Designs

[TSE] The Holy Grails of Web Frameworks with Guillaume LaForge

Under the hood, Grails uses Spring MVC. It has support for "flash scope" between requests.

I find it funny that flash scope is so popular these days, we've had this in AppFuse for four years. However, web frameworks didn't add native support for it until it had a name (provided by Rails). To be fair to Struts Classic, they had support for it before Rails was even invented.

Rather than JSPs, Grails uses Grails Server Pages, which look much like JSPs. Grails uses SiteMesh by default and allows you to easily change the layout used with a meta tag.

<meta name="layout" content="main"/>

Most of the dynamic attributes in a GSP are rendered using the various "g" tags. There's dynamic taglibs for logic (if, else, elseif), iterating, linking, ajax (remoteFunction, remoteLink, formRemote, submitToRemote), form (select, currencySelect, localeSelect, datePicker, checkBox), rendering (render*, layout*, paginate), validation (eachError, hasError, message) and UI (i.e. richtexteditor). [Read More]

[TSE] Good ol' I-95

I left West Palm Beach at 11:30 this morning, seemingly plenty of time in order to make the afternoon sessions at The Spring Experience. Unfortunately, a truck caught on fire on the side of the freeway and stopped traffic for a good hour. So it took me two hours to get here. Damn. I just walked into Guillaume LaForge's talk on Grails, hopefully I can learn something in the last 30 minutes of his presentation.

Update: It looks like I missed a good talk on testing this morning.

[TSE] Using Dynamic Languages with Spring with Rod Johnson and Guillaume LaForge

Spring 2.0 has dynamic language support. To make it work, you do need a Java interface as a contract between callers and dynamic beans. There's no special requirements on the interface. It's a "POJI" and doesn't have to extend or implement anything. For example:

There's 3 ways of configuring Groovy beans:

1. GroovyScriptFactory <bean> element defining source location and properties
2. <lang:groovy> element from a <lang> namespace
3. POBD (Plain old <bean> definition) - this is unique for Groovy since it can be compiled into Java bytecode

[Read More]

[TSE] Rapid Web Application Development with Rob Harrop

There's a couple of other sessions I should probably go to, namely Juergen's talk on Transactions and Mark Fisher's Message Driven POJOs Rock! However, transactions is generally a pretty boring topic and I don't see myself developing any MDPs in the next two weeks. If you don't use your knowledge in two weeks, you generally lose it, so I'll wait to learn more about MDPs until someone pays me to. I know a fair bit already, so I don't know that there's a whole lot more to learn.

I'm attending Rob Harrop's Rapid Web Application Development Essentials talk. With any luck, I'll learn some new tips that we can use in AppFuse.[Read More]

AppFuse and Groovy/Grails?

Here's an interesting e-mail I received last night:

I see AppFuse's strong points is in integrating a lot of oss in a synergistic manner, which is really great and helpful. Just wondering whether there is any chance of integrating AppFuse with groovy and especially grails.

I also just found out about grails 0.1 and it looks really promising, for a 0.1 release.

I just feel that it has some synergy there, a java ruby on rails combines with the best oss integration available.

My response:

I think Grails and AppFuse are more likely competitors rather than compatible. Grails uses Spring, Spring MVC and Hibernate under-the-covers, whereas AppFuse uses the raw frameworks. Of course, it would be cool to allow different classes w/in AppFuse to be written in Groovy or JRuby. At this point, I think it's probably better for users to choose one or the other.

Grails definitely looks cool, and a lot like Rails. However, I think using Groovy is a pretty big step for the majority of Java Developers out there. If you're reading this post, you're probably not in the majority.

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?

Seam 1.0

I've posted my thoughts on Seam 1.0 to my Virtuas blog. What are your thoughts?

It's great to see the release of Seam 1.0. Seam is similar to many full-stack frameworks like Rails, Rife and AppFuse in that it gives you all the pieces you'll need to build a kick-ass web application.

I've blogged my thoughts on Seam before, so there's no need to do that again. I like the idea, especially the lack of interfaces and the 3-files-for-each page idea. However, I don't know that this concept will fly with Java developers. I agree there's a need to simplify, but many of us are mesmerized by the de-coupling that Spring gives us. So now we're programming to interfaces, and every-so-often swapping implementations. I don't know that we can switch to this simpler model. And then there's the "EJB" thing. I think there will be a fair amount of developers that don't use EJB3 simply because it has the "EJB" name. The best thing the EJB Expert Group could have done for EJB3 would be to give it a new name.

The other thing I worry about with Seam is that it wasn't developed from an existing application. AFAIK, it didn't get extracted from a real-world application that had all the problems that Seam solves. I know that Gavin is a smart guy, and he's probably seen these problems in the real world, but there's nothing like developing a real-world application with a technology - and then extracting the framework from that.

In reality, I'm probably jealous. Seam has some really cool features, JBoss has done a great job of marketing it, and it seems to be a really cool way to develop applications. If I'm going to make AppFuse a direct competitor to Seam, it's gonna be quite the uphill battle.

Scaling with Rails

Whenever I talk to developers in the Java community about Rails, the first question out of their mouth is usually "But can it scale?" Today, David has written a nice post titled It's boring to scale with Ruby on Rails.

The one thing that I see time and time again is that Java developers don't seem to realize that some of the highest traffic sites on the net are using LAMP stacks similar to what Rails advocates. IMHO, I don't think "Rails can't scale" is a valid argument. In fact, I don't know if there's any argument or way to put down Rails anymore.

As a developer, my guess is the rates for programming in Ruby developer are less than for programming in Java (unless you're a Ruby Superstar of course), so that's one reason not to program in it. However, since Rails is one of those new bright and shiny things, chances are you might be able to get high rates for it. As far as Enterprise Adoption of Rails, unfortunately I think that's still pretty far on the horizon. I think the hardest part is convincing management that they'll be able to find developers to support it. Mind you, I didn't say good developers, just developers. Period. This is information I've gathered from talking to my Java developer friends.

Try convincing a Fortune 500 company to program in Rails vs. Struts and they'll probably choose Struts because there are thousands of Struts Developers. Is this a good decision on their part? I don't think so. I think it's more important to hire smart people that can learn a technology, rather than hiring those that know a technology. Of course, if someone knows a technology really well, there's probably no harm in hiring them.

I think Rails can become a real contender in the Enterprise if managers can be convinced that it'll be easy to maintain Rails application. Remember that most of software cost is maintenance. Because of this, the whole "it's super productive to develop with" doesn't matter so much - does it? Are Rails applications easy to maintain? My guess is yes, but how do you convince CTOs and CIOs? Another thing I think Rails needs for Enterprise Adoption is good tool support. Drag and Drop type of stuff. Why? Because management loves that stuff (because then they can develop apps) and it's a great sales tool. ASP.NET has been successful because of Visual Studio, not because of its ease-of-use and simple syntax.

Will I learn Rails and use it to develop applications? I certainly hope to, but it's hard enough convincing companies to use something other than Struts - so I don't know if I'll have much luck in selling Rails. The one cool thing about my new job at Virtuas is its an open source company, not just a Java open source company. This opens the doors for me to learn about Rails (and others) and compare them to Java Web Frameworks.

Update: Aaron Rustad has written an interesting article for DeveloperWorks that compares Rails to Struts+Hibernate: Ruby on Rails and J2EE: Is there room for both?

PHP vs. Java - which is better?

I have a former client that has a customer. This customer asked them - "so when are you migrating from Java to PHP?" So evidently this person has the impression that the next wave of web applications will be written in PHP. My former client has asked me to provide an answer for their customer. If I translate it, I think they mean to ask "what is different between Java and PHP and why should we use Java over PHP." Here are my opinions - please add yours as you see fit. I must admit I don't know a whole lot about PHP, except that it's widely popular among the Linux/Apache/MySQL crowd and that it's similar to ASP in it's lack of a MVC architecture (yes, I know about the PHP MVC project).

• I think Java is more of an industry standard, whereas PHP seems to be popular among hackers and hobbyists.
• Java provides better separation of layers - key for testability. PHP has all the code embedded in the page, so you have to run it through a browser to test if database connections work (for instance).
• Java is more scalable.
• More folks know Java and it's easier to qualify someone's Java skills. How do you test someone knows PHP? Is there a certification?
• More for-profit organizations use it.

If you're a Java or a PHP-lover, I'd love to hear your opionions (facts are always better). I'm going to point my client to this post, so keep it clean.