Groovy

Session Notes – Grails Quick Start

Posted on by Matt Woodward

Presenter: Dave Klein – Author of Grails Quick-Start Guide (Pragmatic Programmers)
http://gquick.blogspot.com
http://twitter.com/daveklein

  • groovymag – 20% off with code 2gx1
  • Sample App – Java UG Mgmt App
    • Domain model:
      • Speaker
      • Meeting
      • Sponsor
      • Member (member data already in legacy db)
  • Groovy properties
    • by declaring, they automatically have get/set methods generated
    • can override these if you need to implement something specific in get/set
    • when you access properties via dot notation, behind the scenes it’s calling get/set
  • constraints
    • these determine the order in which things are listed in the list and form views
    • by default string fields get 255 varchar in the database
    • if you use a maxSize in the constraints this gives you a textarea on the edit page and a larger text data type in the db
  • toString method
    • by default this will be the class name and the ID
    • good idea to override so toString calls output something more useful
    • particularly helpful with drop-down lists since grails calls toString() on domain classes when generating drop-downs
  • custom validators
    • use groovy code to implement your own validation
    • can be inline in the constraints block or can be a separate closure
    • def meetingTimeValidator { val, obj ->
      def gc = new GregorianCalendar()
      gc.time = val
      gc.get(Calendar.HOUR) == 18 } // ensures meeting time is at 6 pm
  • unit tests
    • mockDomain() — allows to test domain classes in an isolated manner
      • e.g. mockDomain(Meeting, []) — this gives you an empty list and will be what’s accessed in your unit tests
      • this also gives you all the dynamic methods (GORM, validate(), etc.) in your mocked domain
    • remember that stubbed out tests will pass even though you haven’t implemented them, so you’ll see passing tests when you run your tests even though they aren’t doing anything
    • unit tests run quite a bit faster than integration tests
  • using a “real” db
    • just drop JAR for db drivers in lib directory and set the JDBC URL
    • dev, test, and production environments in DataSource config file
    • for production recommend using JNDI so you don’t have to store user name and password in the config file
  • mapping to existing data
    • e.g. member table–id field is member_num; Grails by default uses “id” as the id field name
    • other fields change to all lowercase and add underscores between words, e.g. firstName becomes first_name
    • table names by default are domain name singular (e.g. member not members)
    • if all this doesn’t match up, need to add a mapping block to the domain class
      • in case of Member class, id and email fields aren’t named correctly, and the table name is plural
    • static mapping = {
      table ‘members’
      version false // grails adds this to all your tables; used for optimistic concurrency
      id column: ‘member_num’
      columns {
      email column: ’email_address’
      }
      }
    • can use existing Hibernate XML mapping files instead of using DSL for mapping on a class-by-class basis
    • in this case a new field was added to an existing table; grails updated the schema but didn’t alter the existing fields in the table
    • basically will always add new fields and will make any other changes based on constraints if the changes are non-destructive
      • e.g. won’t shorten the length of an existing field
  • init block in Bootstrap
    • great place to stick test data–generate data so it’s available when the app fires up when you’re using the in-memory dev db
    • can check environments in bootstrapper so it will do specific things based on the environment the app is running in
    • new in Grails 1.2 is failOnError in save method
  • generate-all command
    • can do grails generate-all “*” to generate controllers, views, and tests for all domain classes
  • grails 1.2 uses tomcat instead of jetty for servlet container
    • also in 1.2 much of what was previously built in is now plugins–1.2 start page shows installed plugins
  • using multiple datasources in a grails app
    • a bit messy–lose a lot of the GORM methods on anything other than the primary datasource
  • can combine create forms across domain classes
    • e.g. in the meeting form, can add the fields to create the speaker on the fly
    • refer to other domain class (speaker in this case) using dot notation:
      <g:textField name=”speaker.firstName” value=”${meetingInstance?.speaker?.firstName}” />
  • save methods in controllers
    • params is a map containing all the fields from the submitted page
    • params will map directly to domain classes in constructors
      • e.g. def meeting = new Meeting(params)
        • maps all the params by name to the Meeting domain class properties
        • if you have nested classes, e.g. speaker, sponsor, maps those as well
      • you do need to save the objects in order for the final save to work correctly
    • if you want to manually flush the hibernate session pass flush:true to the save method
    • flash scope used for storing data for the current request and the request immediately following
      • easier than using session and having to clear it out later
    • validation happens automatically when save() is called, but you can call it explicitly as well
    • controller actions are transactional by default, but you can control this explicitly as well
  • services
    • these are spring beans
    • autowired by name
      • to use, def myController
    • can inject into controllers, domain classes, taglibs
    • help keep controllers cleaner and leaner
    • not the right place for the domain logic (avoid anemic domain syndrome)
    • can create manually or use grails create-service
    • generation script by default sets all service methods to be transactional
      • if one service method calls another, it will be transactional
    • PersonService used in conjunction with Member, but there’s no person class
      • works because in Groovy, don’t need to use inheritance — all by behavior
  • plugins
    • over 300 plugins available
    • 47 javascript plugins
    • 21 security plugins
    • 36 css plugins
    • easy to install — grails install-plugin pluginName
    • http://grails.org/plugin/home
  • grails ui plugin — based on YUI library
    • provides
      • DataTable
      • Dialog
      • Auto-Complete
      • Accordian control
      • more
    • e.g. better date picker than default drop-downs used for selecting dates
      • just replace g:datePicker with gui:datePicker in gsp pages
      • declare the tablib and the specific resources being used on each page
        • this way it only loads what you need
      • this returns the date to the controller as a string, so have to modify the controller a bit
        • params.dateTime = new Date().parse(“MM/dd/yyyy hh:mm”, params.dateTime)
        • default grails datepicker does this step automatically
  • url mapping
    • create more meaningful urls
    • help to hide implementation details
    • gateway to REST in grails
    • e.g. find meeting by year and month
    • update show action to support new url mapping
      • def show = {
        def meetingInstance
        if (params.year) {
        meetingInstance = findMeetingByMonthAndYear(params)
        } else {
        meetingInstances = Meeting.get(params.id)
        }
        }
  • gsp tags
    • build reusable components
    • get code out of the view
    • make pages more readable/maintainable
    • encapsulate domain knowledge
    • very easy to create

SpringOne2GX – Day 1 Keynote

Posted on by Matt Woodward

Brain dump of the SpringOne2GX day 1 keynote featuring Rod Johnson, Graeme Rocher, and others.

  • Major tenets of SpringSource
    • simplification
    • community
    • innovation
  • simplification
    • amount of code in Spring apps has decreased over time as the amount of code in Spring itself has increased
    • framework does more so you do less
    • nice chart showing number of lines of code in Spring sample apps over time
  • community
    • large–Gartner estimates at about 3 million developers
    • traits of community: passionate, highly skilled, think for themselves
    • get involved!
      • ask/answer questions on mailing list and forums
      • submit features and bugs to JIRA
      • participate in events (UGs, meetups, etc.)
      • start a UG or meetup in your area if there isn’t one
      • contribute code
        • doesn’t necessarily have to be core code–extensions, tests, plugins, etc.
  • innovation
    • everything can be improved
    • always new challenges to overcome

Spring 3.0

  • simplify configuration
  • MVC improvements
  • REST support built in
  • support for JSR-330 (DI via annotations)
  • Spring Integration — demo
    • concept: “have Spring all the way down in your stack”

Groovy/Grails

  • all about productivity
  • integration all done for you
  • more prescriptive
    • while Spring is about choice, that means more configuration
    • Grails takes away some choice, but the trade-off is increased productivity
  • Groovy/Grails state of the nation
    • huge growth in recent months–150% increase in traffic to web sites
    • Groovy 1.7 and Grails 1.2 released coming soon
    • big performance improvements in Grails 1.2
    • plugin ecosystem very healthy
      • 25 million lines of user contributed code in 300+ plugins
      • cool stuff going on with alternative persistence mechanisms (e.g. CouchDB), RIAs, etc.
      • iPhone ads: “there’s an app for that” — Grails: “there’s a plugin for that”
    • Challenges
      • IDE support–gets much better with newest SpringSource Tool Suite (STS)
      • hosting/cloud — need better support, easier deployment

Lifecycle and Tools

  • Build -> Run -> Deploy
  • tc Server developer edition — free download
    • really nice dashboard with performance and health insight
  • Spring Insight Dashboard demo
    • real-time performance graph
    • huge amount of detail you can drill into by clicking on a request
    • links back to STS–takes you right to the relevant spot in the code
    • app health screen tracks performance by component over time
      • uses 99th percentile so you’re focused on what most users are experiencing
  • SpringSource Tool Suite
    • Eclipse based
    • single download for everything, including tc server

Keys to Future

  • developers
  • simplification
  • innovation
  • community
  • SpringSource + VMWare
    • VMWare committed to community and open source
    • VMWare serious about middleware

Groovy Goodness: Using Groovy on the Command-Line

Posted on by Matt Woodward

We can use Groovy on the command-line to evaluate one-line scripts and pipe output to other commands or use input from other commands. This makes for some command-line scripting. We invoke groovy with the -e argument to evaluate a simple script. We can even use arguments in the script.

One of the other things I’m loving about getting into Groovy and Grails is the ability to use Groovy for command-line scripting. Some really powerful stuff can be accomplished very simply with Groovy.

More N00b Grails Errors – When a Domain Class Isn’t a Domain Class

Posted on by Matt Woodward

I figure as I make my travails with Grails I’ll post stuff I run into so
others can benefit if/when they jump into Grails.

Today I started a new Grails application and created a domain class and a
controller for User. These were in packages but that’s irrelevant, so I’ll
keep things simple for the purposes of the example.


grails create-domain-class User
grails create-controller User

I then edited my User class:

class User {

String email
String password
String firstName
String lastName

static constraints = {
email(email:true,unique:true)
password(blank:false)
firstName(blank:false)
lastName(blank:false)
}

}

And edited my controller to add the scaffolding:

class UserController {

def scaffold = true

def index = {}
}

When I fired up the app I got an error to the effect of “Can’t scaffold
because User isn’t a domain class.” Weird. Since I hadn’t spent much time
on anything yet, I nuked my domain class, controller, and test files and
started again.

This time around the app ran but I got a 404 error when clicking on the
UserController link on the index page:

/WEB-INF/grails-app/views/user/index.jsp

RequestURI=/myapp/WEB-INF/grails-app/views/user/index.jsp

Very odd it’s looking for JSP, but it dawned on my that I told it to
scaffold AND I had an empty index action defined, so remove the index
action and voila, all is right with the world.

If you got this far and are thinking “DUH!”, remember that I warned you
with the “N00b” declaration in the title. 😉 I’m sure other people are in
the same boat I am, namely augmenting skills they have in other languages
and technologies with Grails, so even if it’s a no-brainer for those more
familiar with Grails I figure I’ll share anyway. Expect my Grails posts to
get more interesting the more I dig into Grails.

Note to self: Grails integration tests fail with static delcaration before constraints

Posted on by Matt Woodward

Ran into this today and it was semi-tough to hunt down so I figured I’d post it since lord knows I’ll forget this sometime in the near future.

If you have a class as follows:

class User {
  String firstName
  String lastName

  static constraints = {
  }
}

And an integration test like so:

import grails.test.*

class UserIntegrationTests extends GrailsUnitTestCase {
  void testSave() {
    def user = new User(firstName:'Matt', lastName:'Woodward')
    assertNotNull user.save()
  }
}

You may find Grails throwing this error when you run your integration tests:

No signature of method User.save() is applicable for argument types:() values:[]

Bit of a weird error but from what I can tell, the integration tests don’t like the way the scaffolding formats that constraints block. I reformatted without the line break at the tests pass, and now even when I put things back the way they were, the tests pass.

Hope that helps someone else’s head and the nearest wall if you’re starting to dig deeper into Grails.

I’m Having a Crisis of Faith After a Weekend with Grails

Posted on by Matt Woodward

I have a confession to make: I cheated on CFML this weekend. And I enjoyed every minute of it. Heresy, I realize, but if you stick with me through this brain dump I hope you’ll see that despite the sharp criticism contained herein, I’m extremely optimistic about the future of CFML. We just have a helluva lot of work to do.

To set the stage for things, I’m embarking on a side project with a friend of mine and as usual it’s a big job with a tight deadline. None of this is anything new and previously I wouldn’t have thought twice about which technology to use. CFML: Now More Than Ever. (Sorry, I just love that bumper sticker.)

I’ve been taking several runs at Grails over the past year or so, and with a semi-free weekend I decided to re-read a few books and some issues of GroovyMag. Basic requirements for the aforementioned project in front of me on Protoshare, I figured I’d give myself an hour to get a couple of the domain classes up and running in Grails. I downloaded fresh versions of Groovy and Grails and set off to work.

I didn’t need the whole hour. I didn’t even need half an hour. About 10 minutes after getting everything installed, and this included reading a couple of refresher instructions (and truth be told I ate a little sushi while doing all of this), I had my basic domain classes that involved a one-to-many relationship done, persisting to a database, tested, and the basic Grails master/detail views and CRUD functionality up and running. And before you think an IDE of some sort was lightening the workload, I did all of this in a terminal using vi.

Whoa.

Granted, I’ve done this sort of exercise before so Grails wasn’t totally new to me. For someone new to Grails you might have needed the whole hour. 😉 Previously though, I’d screw around with inconsequential “Person” or “Book” or “ToDo” classes and think, “Impressive, but if I were doing this for a real application there’d be much more to it.” But this time around I was starting at square one on a real project, so in my mind I was looking at Grails from the standpoint of building a real application with it.

I proceeded to build out more of the application, fully expecting to lift up a stone and find some nastiness I couldn’t live with, but the hidden gotchas never came. Grails simply delivers.

A Concrete Example

Before moving on to my counterpoint that sets up the rest of this post, let’s take a quick detour to see how Grails does what it does. To prove I’m not blowing smoke, this–literally and with no omissions–is what you have to type in a terminal to have this working Grails application up and running. (Be nice if you add stuff there. Your mother might read it.)

First, you create the application and have Grails generate a couple of objects:

grails create-app UserTest
cd UserTest
grails create-domain-class User
grails create-controller User

That creates the application and two files, User.groovy and UserController.groovy.

You then add this to User.groovy:

String email
String firstName
String lastName

You then add this line to UserController.groovy:

def scaffold = User

And finally, you run the application:

grails run-app

That’s it. You’ve just built out the basic CRUD operations for a User class in about two minutes. And if you don’t like the terminal, NetBeans makes this even easier.

Want to deploy the app to another server? Type:

grails war

Then drop the generated WAR file on any Java servlet container. Granted this is using HSQLDB at this point, but having it point elsewhere is a matter of tweaking a DataSource file and setting your production database to whatever you want. Grails is smart enough to handle different environments (e.g. development vs. production) and use the production database settings when you generate a WAR. (Yeah, they pretty much thought of everything.)

Stark Contrast

Back to my experiment. With some basic functionality for my app up and running so quickly in Grails I decided to open up Eclipse and go through my usual process of developing this same functionality in CFML. I’ll be completely honest and say that this is not a fair fight, which kind of gives away one of the punchlines of this post, so read on …

I haven’t ever been a real fan of any of the code generators available for CFML, nor have I ever delved much into the CFML ORM tools. This is not a slight against the authors of those tools in any way; I’ve just always preferred to do things by hand. I do use Peter Farrell’s Rooibos Bean Generator regularly since writing beans is pretty much the definition of drudgery, but my Mach-II listeners, my service layer, my DAOs, etc. have all been written by hand.

Why? Because I’m a control freak. Every time I’d try a code generator or ORM I’d be thinking, “That’s not exactly the way I’d write it,” or I’d be wondering what the heck the ORM was doing under the hood, or I’d be concerned about performance with an ORM, or any number of other excuses, so I never made the leap. I didn’t want to give up the control. And I type fast enough and have done enough of the basic grunt work that it’s not as if I was adding a ton of time to my projects. A few days on most typically sized projects for me and the basic plumbing would be done. Not so bad.

To even begin to approximate the Grails test I started from scratch with the CFML application as well, other than my existing Eclipse/CFEclipse and Tomcat installation. (For those who aren’t aware, Grails comes with literally everything you need to run it including Jetty.)

I downloaded an Open BlueDragon WAR, Mach-II, the Mach-II Dashboard, the Mach-II skeleton, and ColdSpring … all the familiar faces I’m used to seeing in most of my projects these days. I then set out to write all the same code that existed in the application that Grails scaffolded for me, which involved:

  • Creating a database (I used H2 to keep things simple)
  • Creating two domain classes with a one-to-many relationship between them
  • Creating a controller for each domain class
  • Creating a list view and the related queries for each domain class
  • Creating an add/edit form and the related queries for each domain class
  • Creating unit and integration tests for each domain class

In short, all the stuff you’d need to get a nice head start on the backend of any web application, and nothing more than what Grails gave me in 10 minutes.

I downloaded files. I unzipped files. I moved files around. I edited config files. I wrote code. I edited more config files. I wrote more code. I wrote a lot of freaking code.

A couple of hours later, I had something that approximated my stopping point on the Grails experiment. But it wasn’t as nice, and I had to be honest with myself: it was a horrendous amount of work by comparison.

I didn’t even get to the testing part, for which I would have had to download MXUnit and create test CFCs and functions. I gave up and went to bed.

It’s All Relative

Before people think the situation is too dire, let’s keep things in perspective. Creating a working prototype of a couple of major pieces of a web application in a couple of hours really isn’t that bad in the greater scheme of things. As I said earlier, it’s not as if we’re talking about adding weeks to a project schedule by doing things this way (though I suppose on huge projects time spent here would add up). And of course if all I wanted was pure development speed I could have done old-school CF 5 style development and been done with it, but that’s not a good way to lay the foundation for a extensible, maintainable application.

On the other hand, everything’s relative. After the instant gratification from Grails I had to face the fact–and I hope everyone understands how difficult this was for me–that working with CFML was like running in bare feet on the sand, and working with Grails was like having that jet pack we’ve all been promised for so long.

I didn’t plan on winding up where I did when I fired up Grails the other night. It’s not as if I’m fed up with CFML and was looking for something different, and I had no intentions of taking a bit of a hard right turn on this particular project and going with a technology that truth be told I’m still not all that familiar with. But here I am. And I’m not sure I can look back.

No, This is Not One of “Those” Blog Posts

I’m not going to make a big speech about how I’m “leaving CFML” to raise a ruckus and get some attention. I care a great deal about the future of CFML or I wouldn’t spend so much time on it. But the longer I’ve been in this business, and the longer I’ve been using CFML, and given all the tools and languages I’ve seen come and go over the years, I’ve become a lot more pragmatic than I used to be.

I’ve gone down a couple of dead-end paths over the years (any REBOL fans in the house?), and although each of us tend to have what amounts to a love affair with a particular language–the one we keep going back to time and time again, and the one that will always have a special place in our hearts for more emotional that practical reasons–we owe it to ourselves and the technology we love to be open to other possibilities, and to be brutally honest when something comes along that just plain works better. Admitting that isn’t admitting failure: it’s admitting that you care.

If we don’t ever look outside our own little world, preferring instead to contemplate our navels, live blissfully in Lake Woebegone, and engage in full-blown siege mentality when we’re threatened, then I’m sorry, that’s not being dedicated to the technology we love. That’s coding while Rome burns.

I realize this sounds pretty dismissive of CFML. It’s not, but that’s another punchline coming a bit later. CFML is the first programming language I learned after HTML, and 12 years later I’m still using it and still extremely excited about where it’s going, particularly with the shiny new open source movement in CFML.

All this being said, I simply can’t shake the experience I had with Grails the other night. The contrast between a sophisticated, well-thought-out, extremely well-executed, comprehensive framework like Grails (not to mention the elegance of the Groovy language) and the comparable tools we have available for CFML is too striking to dismiss or ignore. And again, that’s not to denigrate the fantastic work anyone does on any of these tools. Remember, I’m involved with some of them myself and I don’t plan on stopping those efforts. They’re great at what they do, but what they do is no longer enough.

As I mentioned earlier I’ve taken a few stabs at Grails so I’m not quite sure what was different last night. Probably a whole lot of thoughts and directions and changes in my attitudes about things came together in a particular way and at a particular point in time and space, but whatever the reason, Grails opened my eyes wide last night, and I simply can’t dismiss that. To quote one of my favorite movies, “How you gonna keep ’em down on the farm once they’ve seen Karl Hungus?”

What Changed?

If I’m totally honest with myself, probably the biggest change in my attitude towards development these days is I just want things to work. After writing CRUD code for so many years, not being willing to give up any control, and convincing myself I was doing my application a favor by writing every single line by hand, I’m tired.

CRUD crap (is that redundant?) is a commodity. Basic object generation is nothing more than a means to an end. Your users don’t care a lick about your hand-crafted, finely tuned SQL, or your oh-so-clever service layer, and if you do, I’m reminded of the old adage about peeing your pants: it may give you a warm feeling, but no one else cares. Users want something with a great front end because to them that IS the application. As long as it’s easy to use, it works, and it meets the applicable performance and scalability requirements, the application is successful.

So given the finite amount of time we all have, why would we consciously choose not to use a tool that does the commodity stuff for us so we can focus on the front end and business logic? I know SQL pretty well but I can’t say I enjoy writing SQL. It’s just something I felt I had to do. Same with so much other boilerplate crap. But if I had my druthers, I’d focus more on business logic and UI functionality and have all the persistence nonsense and a lot of the other drudge work handled for me. Not to mention the fact that when I’m using best-of-breed tools to do this, I can rely on the fact that the underlying code has been battle-tested by thousands of users. I can’t say the same for my own persistence code until I put the app into production.

Grails isn’t only about GORM of course. If I just wanted an ORM I’d use Transfer, and ORM capabilities are coming in ColdFusion, Open BlueDragon, and Railo. But Grails is about much more than ORM. ORM alone only gets you a fraction of the way there.

The real secret to the Grails sauce is how overwhelmingly compelling the entire package is, from the Groovy language itself, to GORM, to the fantastic flow and incredible speed of the entire development and deployment experience, to the powerful front-end tag library, to the integrated testing, to the sophisticated and dead-simple AJAX functionality … I could go on. The point is Grails is a complete pleasure to use from top to bottom, and I’m finding it increasingly difficult to talk myself out of taking it seriously.

Apples and … Different Kinds of Apples

Thus far you may have been thinking, “Is this guy a moron? He’s comparing a language (CFML) to a framework (Grails).” To a point, that’s true. But when I’m comparing Grails to CFML I’m just using CFML as a short-hand way of referring to the tools available in the CFML world. So I’m really comparing Grails as a package to the disparate bits and pieces that create some semblance of Grails-like functionality in CFML.

Take Mach-II for example, which in my incredibly biased opinion is the finest MVC framework for CFML. 😉 Peter Farrell, Kurt Wiersma, Brian FitzGerald, and I spend a ton of time on Mach-II, not to mention all the great help from our community, and it’s a damn nice framework. It continues to get better with each release, and with caching, logging, the dashboard, the new front-end tag libraries, and everything else we’ve put into Mach-II and have planned for future releases, it’s a really compelling package.

One of many things that struck me as I’ve been working with Grails is how the basic constructs of Mach-II map one-to-one with Grails. Grails has “controllers,” Mach-II has “listeners.” Grails has a flash scope to persist data across redirects, Mach-II has the same. The Grails docs talk about how to keep your controllers dumb and use a service layer for your business logic, just as we advise in Mach-II. Even the Grails code I’ve been writing, particularly the controllers and services, looks eerily similar to the Mach-II code I write. This is probably why I’ve found myself surprisingly comfortable in Grails so quickly.

But Mach-II is only one piece of the puzzle. To manage dependencies, we need to grab ColdSpring and wire everything together in an XML config file. If we do want ORM, we have to grab Transfer or Reactor and again, more configuration. Then we grab MXUnit for testing, and it’s yet another piece of things that knows nothing about any of the other pieces of our puzzle until we explicitly tell it. If we want to do functional testing we grab Selenium. And round and round we go.

Ultimately it’s not that we lack the tools in the CFML world that give us the ability to do what Grails does. Heck, Grails is based on Spring, Hibernate, JUnit, and other best-of-breed tools in the Java world, so it’s not as if the Grails authors created this entirely from scratch.

What we’re missing in the CFML world is flow, and without good flow you simply don’t have good productivity.

Integration, Integration, Integration

I won’t belabor this point too much since I’ve made it in other ways a couple of times now, but the magic of Grails is the cohesiveness with which all the various bits and pieces of the web development process have been integrated. MVC, DI, ORM, unit and integration testing, functional testing, i18n, AJAX, deployment, documentation, even a run-time environment … literally everything is contained within Grails, and it all works seamlessly. It’s magic.

This elegant integration of what in the CFML world are still very disparate tools is what makes Grails such a joy to work with. I’ve never experienced a better development workflow than what I can achieve with Grails, and this leaves me free to focus on the things that matter most to the success of my application. And for simple applications I can crank stuff out more quickly than ever before.

That’s what I kept coming back to as I fought with myself over whether or not to use Grails for a real-world application. In the end, it’s all about the success of the application and how I can do the best job possible in the shortest amount of time. Much as I love CFML, in this case Grails won out. Even with my years of experience with CFML and relative lack thereof with Grails, I had to have a heart-to-heart with my friend (after the one I had with myself) and tell him that I truly believed I could get things done more quickly and with a better end result than I could with CFML, at least for this particular project. After showing him a demo or two of what Grails can do and writing some live code to show I had nothing up my sleeve he, another long-time CFML developer, had to agree.

Yes, it’s a poor craftsman who blames his tools. But you sure can cut the grass faster with a lawnmower than you can with a pair of scissors.

Why Grails

I’m well aware that this is the honeymoon period between me and Grails. I’m sure we’ll fight. But I’m equally sure we’ll make up. The real test will be building an actual application with it, and I’ll have a lot more to say as I do.

At least at this point in my experience with Grails, it strikes the perfect balance between taking the drudge work out of web development while still letting you have full control over the stuff that matters. This is the promise of CFML, but compared to Grails we’re not there yet.

As for going with something like Spring, I like Java, I really do, but Java Sucks Ass. It’s documented. (Be sure and read the follow up post to that one.) So Groovy gives me a faster, dynamic version of Java, and Grails gives me a fantastic toolkit to get great stuff done quickly. This way I keep what I love about Java in the mix without having to make a massive sacrifice in productivity.

Can Ruby on Rails do all this stuff for you? Sure. Grails used to be called Groovy on Rails (no way!) until DHH requested a name change (at least that’s what wikipedia says), so clearly the Grails folks thought Rails had a ton of good ideas in it. I’ve also dabbled in Ruby and Rails a bit over the years, but as a language Ruby just doesn’t do it for me. I’m sure many people out there love Ruby, and that’s fine. For me Grails is a much better fit, not to mention the 100% seamless integration with Java when I need it.

Why Doesn’t CFML Have a Killer Framework Like Grails?

Honestly I’m not even sure the “why” even matters. I have some ideas about why CFML isn’t farther along than it is given its lengthy history, but I’ll save those for another post. Fact of the matter is we have the makings of what could be a great development experience, but we don’t have the whole enchilada. Not by a long shot. We deserve better. We can do better.

What would make up a Grails-like framework in CFML? Here’s the basic pieces:

  • CFML runtime
  • MVC framework
  • ORM framework
  • Logging
  • Caching
  • Unit and integration testing framework
  • Front-end/functional testing framework
  • JavaScript/AJAX framework
  • Templating engine
  • Command line tools for code generation, scaffolding, deployment, etc.

If you’re saying “we’ve got all that,” on most points you’re right, and with the view tag library in Mach-II 1.8 we’re even getting there on the templating engine front. But we’re still lacking all of this in a single easy-to-use package that increases our productivity in CFML by leaps and bounds. One could argue there’s still less typing in CFML than in other languages, which is a dubious argument at this point given things like Ruby and Groovy, but we’re still lacking the proper tools to truly make developing an application, not just writing code, far more productive in CFML.

So let’s go down the list and figure out how we’d make this happen.

Building the Perfect Framework

You can’t run CFML without a CFML runtime, so the CFML engines are certainly part of the puzzle. My only cautionary statement here is we can’t rely on them to give us the CFML version of Grails. In my opinion that isn’t their job. To create a development experience similar to Grails, having the ability to easily plug in and distribute (that’s key) a CFML runtime is crucial. The distribution part is where Adobe ColdFusion is a non-starter, but of course the magical CFML framework that exists in my head would allow you to choose OpenBD or Railo as your runtime, and those could be bundled, or you could plug Adobe CF in after the fact if you so choose. To me having everything in a single downloadable package eliminates one more headache and much more closely approximates what you get with Grails.

ORM is another piece of the puzzle. We have Transfer and Reactor now, and we have ORM support being baked directly into the CFML engines as we speak. Again no offense to the Transfer and Reactor folks, but I think once Hibernate, or JDO, or some other implementation of the JPA is baked into all the CFML engines, or even just available as a seamless add-on to CFML, we’ll have a much bigger step forward on this point. I’ve used Transfer a bit and it works great, but there’s no substitute for the thousands of man hours of development and testing, not to mention the wide usage, of the ORM tools in Java. Java’s just a much bigger pond and I think we can benefit greatly from leveraging it whenever we can.

As for MVC, here’s where I’m going to get myself into trouble, but I don’t think the CFML world needs a dozen MVC frameworks like we have now. The CFML community is way too small to have so many people spending so many man hours reinventing the same wheel over and over again. Now of course I’ll admit my bias and say I think as a whole Mach-II gets us closest to the final result we need, but ultimately what I’d like to see is all the framework authors working together towards a common goal even if the people behind the various frameworks still choose to do things their own way. Maybe the magical framework in my head exposes an API that all the MVC frameworks implement so you’re free to pick your poison on that front as well. (As you can tell, I’m still thinking through how all this would work.)

As for the rest of the pieces the choices are obvious. For JavaScript and AJAX, jQuery would be rolled in but you could use another framework if you choose. Pluggability is key here as well. Mach-II is well on its way to having a full templating engine built in, but there may be other projects out there in CFML land that I’m not aware of. For unit testing we have MXUnit. For front-end testing we’d have to leverage something like Canoo, or maybe Selenium is equally configurable and scriptable (haven’t looked at it in a while).

Command line tools are where things get interesting since you can’t run CFML commands from a terminal. (Anyone working on that?) So, two thoughts come to mind. Either this is all web-based, which is OK, or Java and ANT are used to do the command line pieces. Maybe we have both options. (I can ask for the world when this all exists only in my head.) I do think the command line bit is key, not only because I like working that way, but because it’s a faster, easier way to do things than clicking around on web pages.

So put all this and some awesome scaffolding together and you’re done! Yes, I realize what I’m proposing is a tremendous amount of work. Grails was three years in the making before it hit 1.0. So it’s not that it can’t be done, we as a community of framework authors and CFML advocates just need to commit to making it happen and start chipping away at the mountain of work involved to get there.

The Punchlines

I said I had some punchlines, and though you’ve probably assembled then in your head by now after reading everything to this point, I’ll just enumerate them so they’re more, uh, punchy.

  1. Grails kicks ass, and we deserve something this awesome in the CFML world. We should have had it by now. We don’t need more frameworks, we need to demand more from our frameworks.
  2. We need to collaborate more as a community and work towards common goals instead of everyone being off in their separate caves cranking out code that does the same thing as what the guy next door is writing. Specifically I’m targeting those involved with framework projects, myself included. I’m not even necessarily proposing one framework to rule them all, but it does seem a bit silly that as a relatively small community we spend such a huge amount of time and effort to wind up with such subtle differences in how the various frameworks do their respective jobs.
  3. We need a vision. I’ve tried to present one here, although as you can tell at this stage it’s still a bit cloudy. But we need to open up the dialogue and remove our egos and biases from the picture and answer the question: What would the perfect set of tools for CFML development be?
  4. We need an action plan. I haven’t thought that far ahead quite yet, but the first thing that comes to mind is a framework authors mailing list. Maybe there already is one. And it’s key that this discussion be completely open and anyone who has interest, framework author or not, can participate. From these discussions we can quite easily come up with a high-level, concrete set of tasks and goals and get to work. I’m not saying it’s going to be easy, but on the other hand I feel like we have all the basic building blocks available, so how hard can it be? 😉

Who’s With Me?

If the ideas in this post scare you, good. They’re meant to. But they’re also meant to motivate you. If you care about CFML as much as I do, then I hope you have the courage to admit that we’re falling behind and that we need to do something about it. This doesn’t mean blogging, and twittering, and conferencing, and defending CFML against all enemies domestic and foreign, and all the rest of the community-oriented stuff we all do. This means coming together as a group, knuckling down, and doing some seriously hard but even more seriously rewarding work from which we all will benefit.

We can do this. We need to do this.