Is it ColdFusion or Groovy?

Mon, 03 Nov 2008 17:52:00 -0400

Here at Broadchoice we've been working on our new product for close to three months now. I've gotten a crash course in Groovy, Spring, and Hibernate, all of which are slightly familiar to me from my time with ColdSpring, Transfer, and Java. I'm really digging these new technologies, but of course, I'm a die hard ColdFusion user at heart. A few weeks backs I needed to work on a quick iPhone web application prototype. Joe set up the connection and all I had to do was write CFML (lucky me). Little did I know that along with setting up basic CFML compatibility on the server, Joe also added one of the slickest things I've seen ever in my life as a developer. The application I'm working on is pretty simple, but I wanted to use Model-Glue 3 for it since - well - you never know when a simple prototype will turn into a large, complex application. The following code snippet comes from a controller used to load bookmarks:

Nothing in the above code should be too odd or even that exciting really. I'm using a service (injected via the beans scope in Model-Glue 3) to retrieve my content. My controller begins with...

Note the beans value specifies which beans configured in ColdSpring should be passed to my controller. I love this new automation in Model-Glue 3. If you open up my ColdSpring.xml file, you will see my beans configured:



    
        
            /some url you dont need to know
            /something else you dont need to worry about
            10

Hmmm. Ok, there's my config bean, wheres my contentService bean? Oh yeah - here it is:

You can find the above in our Spring file. Just in case the above didn't quite make get through, let me make it real nice and obvious:

The above line of CFML is using a bean injected from Spring, not ColdSpring, and points to a Groovy file. This is the same Groovy code used to drive the AIR application. No createObject("java") here baby. I'm using the Groovy code just like it had come from a CFC. This is done using a ColdSpring/Spring adapter that Joe wrote. It lets ModelGlue get Java-based beans from Spring. (I'm simplifying it here a bit, but hopefully you get the significance of that!) Once that connection is done, you can easily get beans from the Spring file and inject them into your controller. So for example, when my UserController wanted do handle login, I added: beans="userService,config" and then simply ran a userService.validateAndLoad on the authentication information. It's always been easy to use Java from CFML, but never has been so sexy! Now to be fair, I did have to use a JavaCast once or twice, but not nearly as much as I would have thought.

Writing your Second Model-Glue Application

Thu, 14 Aug 2008 18:45:00 -0400

So the title is a bit of a trick. This really isn't about writing your second Model-Glue application, but more about the kinds of things you see when comparing earlier Model-Glue applications to those you write after having a few under your belt. Most likely a lot of what I'm going to talk about applies to other frameworks as well, so this isn't just a Model-Glue concern. When I arrived at Broadchoice, the older version of our product had already been updated to use the Model-Glue framework. The primary developer team behind this update had just learned Model-Glue. A lot of what I saw looked very similar to how I had built Model-Glue sites when I began. Here are a few items to consider when building your next Model-Glue application. Model-View-Controller need not be singular...
For those of us who were new to MVC, the idea of nicely separating back end logic from front end views was a godsend. Sure it meant a bit more work up front, but the benefits later on were more than worth the effort. I think this is the thing I appreciated the most about MVC. So, like most people, I began to work with a controller, a ModelGlue.xml file, and maybe a few model files and my directory of views. This worked fine for a smaller site, but as the site began to grow, my XML configuration and controller file began to explode. When I needed to find an event, I was scrolling through 1000 lines of XML. Even if I used a nice naming scheme (more on that below), it was a chore to work with. When I began using Model-Glue, there wasn't a simple solution for this. Luckily the framework added support for XML includes. I ran into the same issue with my controller as well. The file had become too large to manage. It didn't even occur to me to use multiple controllers until I had done a few Model-Glue sites, but now that I have I wouldn't do it any other way. My typical approach is to break up the controllers by "areas of concern" - which is my way of referring to the major parts of the application. So for example, a typical site may have a User, Product, and News controller. Each would be responsible for handling events related to their areas. So the User controller would handle listening to getUser. Product would listen to getProduct. Etc. I still keep a controller named, well, Controller, because I find that there are typically events that don't fall into any one particular category. I also still put a few events in the main ModelGlue.xml file. What's nice about MVC, and where I think it really "sinks in" for developers new to the concept, is that you can update a Model-Glue site to fix this problem and not lose a drop of functionality. So at Broadchoice, I've been slowing breaking things up a bit when there are available cycles. This has zero impact on the product for the end user but has the side effect of making it easier to update the application. I also recommend breaking up the views folder. It may start small, but before you know it any semi-complex site can grow quite complex. The main idea here is to make it as simple as possible for someone to find the right code when performing updates. Inconsistent Naming
Ok, so this may be more of an issue for those of us who are anal retentive about naming, but I really get bothered when my event names don't follow a standard naming pattern. Inconsistent naming is an even bigger problem if the files aren't properly broken up (see above). There are no hard and fast rules for what makes a good event name. My typical rule is "area of concern"."action", so I will typically have events like:

product.edit
user.authenticate
planet.destroy

This way it's always clear what type of data (or area of the application) is being worked with, and what type of action is being performed. Once again, the beauty of MVC is that you can make these types of corrections when you have time for it. There are two potential problems with this. First - you may have existing URLs that rely on certain event names. In the past I've handled this by either using a URL rewrite or by catching the "missing event" error in Model-Glue. Model-Glue 3 adds support for handling missing events directly so this will get even cleaner. While you should put some thought into how you name your events, it may make sense to pay extra attention to those events the users will actually see (and possibly bookmark). The second problem is a bit harder to fix. If you change the event that is run when a user logs in, it isn't just enough to update the XML. You also have to remember to update the view layer as well. I was never really a big fan of the XFA technique. This is a Fusebox concept whereby you tell the view what to use for particular events. (I believe this originated with Fusebox - if anyone knows better, speak up!) So instead of me hard coding action="index.cfm?event=user.authenticate" in the form tag, I'd pass it to the view layer and make the action dynamic. After doing some refactoring on our product, which made heavy use of XFAs in Model-Glue, I'm really happy they were used. Here is a simple example from one of our views:

Note the use of the value subkey inside the view node. This will add the values to the viewState. You would then use these when creating any links within the view. Anything else?
This is - in general - the big things I've noticed when looking at first generation Model-Glue sites. I'm curious to see what others have discovered as well, so please chime in with your comments. I'll add one more thing to the list - I wish like heck I had made more use of auto-wiring and ColdSpring in general. Until you see a good example of an application that uses this you don't truly get how much work it can save you.

ArgumentCollection - Broadchoice Engineering - Model-Glue

Is it ColdFusion or Groovy?

Writing your Second Model-Glue Application