I’ve been slowly learning Model-Glue recently as you probably know if you’re checking the LineOfThought SVN Repository. What has helped the most recently has been reading over Doug Hughes Reactor Sample Blog application, a Model Glue ap that comes packaged in with Reactor. It doesn’t use Unity, but it’s close enough in it’s setup that it might as well. It uses Coldspring for bean configuration and loads them up when the application starts. It uses facades to access various scopes that shouldn’t be touched inside CFC. I could go on, but there’s still a lot more information for me to mine from this simple application. Here’s some of the most fun stuff I’ve come across, from least exciting to most.

Forwarding a user to another page in ModelGlue.xml One of the biggest adavantages of Model-Glue is being able to look at your XML files and get a top down look at your entire application. What actions do, and where they can send the user off to. The section in ModelGlue.xml is one of the easiest to use to organize this. For example, take the following login events.

<br />
<event-handler name="security.login"><br />
  <broadcasts><br />
    <message name="CheckIfLoggedIn" /><br />
  </broadcasts><br />
  <views><br />
    <include name="body" template="security/dspLogin.cfm"><br />
      <value name="xe.submit" value="security.login.submit" /><br />
      <value name="xe.forgotpassword" value="security.forgotpassword" /><br />
    </include><br />
  </views><br />
  <results><br />
    <result name="LoggedIn" do="home" redirect="true" preserveState="false" /><br />
    <result do="view.template" /><br />
  </results><br />
</event-handler><br />
<event-handler name="security.login.submit" access="public"><br />
  <broadcasts><br />
    <message name="Login"/><br />
  </broadcasts><br />
  <views /><br />
  <results><br />
    <result name="invalidLogin" do="security.login" redirect="false" preserveState="true" /><br />
  </results><br />
</event-handler><br />

The security.login event broadcasts CheckIfLoggedIn. If a controller is setup to listen for this message, such as this one.

<controller name="Security" type="lineofthought.controller.SecurityController"><br />
  <message-listener message="CheckIfLoggedIn" function="CheckIfLoggedIn" /><br />
</controller>

It’ll call the function and run is as you’d expect. Lets say you add a little more code in the SecurityController.CheckIfLoggedIn() method.

[cfm]



[/cfm]

This is setting Results inside the controller. After that message completes, it’ll read the section of that same event. If the user is logged in, the “LoggedIn” result will be set. When a result with the name “LoggedIn” appears in this event, it’ll now execute. This line will redirect the user to the “home” event if the they try to view the login page but are already logged in.

<result name="LoggedIn" do="home" redirect="true" preserveState="false" />

Likewise, the Login message that’s broadcast in the security.login.submit has a similar line:

<result name="invalidLogin" do="security.login" redirect="false" preserveState="true" />

Whenever the Login message adds a result of “invalidLogin” this will forward the user back to the login page without redirecting them. This means that if they hit reload, it’ll be the same as resubmitting the form. If we had changed it to redirect=”true” nothing would happen when the reloaded the page. With preserveState=”true”, all variables available on this page will be there on the login form. This means that we can populate the login form with the username and password they submitted and display a nice little error. Here’s an example of what the login page code looks like when it’s all put together.

Forwarding a user to another page in a controller It’s easy enough to forward the user to another event in the section of a model glue ap, but what about forwarding them on to another page that’s not on your site, or to a dynamic page. Using the tag can always work, but you’ll start over from scratch on that entry page. Like with the tag, you can also someone to another location and preserve state. This is done through a very easy call inside of one of your controllers to the forward() method. Lets say you want to forward someone to their personal homepage when they login — well that’s easy enough inside a controller.

[cfm]






…[/cfm]

And so on for each element you want to set. Model-Glue: Unity has a very slick way of processing this input — by passing it over to Coldspring to do some of the work. In it’s simplest form, the above code can be replaced with just this.

[cfm]

[/cfm]

This line of code will create a “UserRecord” bean using Coldspring, and fill it with whatever values it can find from event scope (things available from arguments.event.getValue()). There are some people who are against adding DAO records to coldspring though, and I’ve run across a few such cases, but MG solves that.
[cfm]


[/cfm]
This code will produce the same result, and you can continue working with your UserRecord bean, now filled.

Source: /modelglue/unity/eventrequest/EventContext.cfc/MakeEventBean() and /modelglue/util/CollectionBeanMaker.cfc/MakeBean()

Actionpacks. These are definitely a features of Model-Glue i haven’t seen enough examples on. Browsing through the svn repo, there is a readme file for a sample Email Actionpack. Actionpacks have the added bonus of being able to be shared across Model-Glue applications because of their modular nature. In your ModelGlue.xml file, just add one line of code right after that first tag and you’ll have the Email actionpack available. The hope is that in the end everything can just be dropped in a single directory of your workspace and after you add this one line everything works!

<include template="/ModelGlue/actionpacks/email/config/ModelGlue.xml" />

There’s a lot of possibilities that come to mind with this, but it’ll take some experimentation and digging to get the concept down. It’s extremely powerful though.

Sitepoint posted in their newsletter in August a comment on Coldfusion, stating it was relatively stagnant. Ben Forta, the Senior Coldfusion Evangelist, contacted Kevin Yank, the author of that statement to gain a little more information on the reasoning. Turns out Kevin did a very nice in depth writeup on his opinions which have turned into a single place for all the Coldfusion developers to come out of the woodwork and respond to. Here’s my long winded response I spent entirely too much time writing.

Original Post on Sitepoint

Great article Kevin!

Sad to see the overall opinion of the language as stagnant, but if that’s the way you saw it, that’s probably how many other people around the world see it as well. Many of the great points about CF have already been brought up, but I thought I’d give me $.02 as a passionate Coldfusion Developer.

I agree that Coldfusion growth is stagnant. I don’t mean the growth of the language, or the growth of the software created by CF, or the skill of the programmers writing it — but as far as the number of new people coming to the language to use it I would have to agree.

As your chart noted there hasn’t been a growth in CF jobs, and the CF conferences aren’t (to my knowledge) selling out (although I did go this past year and learned a ton). What does seem to be advancing however is the quality and power of code thats come out, even in just the past year with Unity, Reactor, Coldspring, RiaForge and many other projects and frameworks. People are getting smarter and it’s showing. MG:Unity, for instance, would be comparable to rails in many senses for it’s RAD possibilities, but I doubt many people outside of the CF world know what it is.

The language too is also improving, faster than the current community can use all the features. Every feature is surely being used by someone, but some features just haven’t hit that viral point where everyone jumps on, like for web services in MX for instance. Flash Forms, report builder, charting — they’re all amazing features that so much could be done with, but how often do you see a site using flash forms? These are those features that when you use them you think “man, this thing saved me countless hours”, but most the time you don’t need them in any language. Speaking of the image stuff, the Alagad Image Component is probably the standard, although as you mentioned it’ll be a feature in CF8.

I think what has in the past scared people away from CF, or at least made them not give it more than a second thought in small to medium sized projects, isn’t even the cost but the lack of knowledge about the product. CF just doesn’t get as much press from the usual developers — it’s usually just when a new version is released that it gets big word of mouth and non-CF people hear about the new stuff. I have a feeling this is because of the blog community. CF has a great blog community, which I’m recently discovering, but it does have one thing limiting it’s growth – confidentiality. Most CF aps are for bigger business than a rails ap, so the bloggers can’t exactly write in depth posts about their experiences. CF’s Mecca is Washington, DC, and I don’t think I’d want to chance my career by blogging about what I was working on. Do a search for Coldfusion on 9rules and the only result you get is an ominous post about Coldfusion being on it’s way out; it’s just not getting the blogosphere crowd so we’re not exactly “winning hearts and minds” of the new programmers.

As your chart shows though, there are more Coldfusion than Ruby jobs available, by a factor of 4. The fact that Coldfusion doesn’t get the huge community press that makes people take notice isn’t that it’s not happening, it’s that Coldfusion is usually dismissed before they see what the fuss is about, so only the people already interested read more. I think videos like Joe Rineharts CF Blog in 15 minutes, or Doug Hughes Presentation on Reactor or anything else from Adobe Developer Week are the kind of thing that make the “new” people deciding on a language really take notice of it and give it a fair chance. Imagine having the rails productivity on a proven, established platform? Not a bad thought, but the community would have to grow to be up for the task.

I don’t usually recommend books unless they change my point of view on something. Granted I read almost entirely tech and finance books, but most don’t make headlines. One i’ve been reading lately makes the grade — Bulletproof Web Design : Improving flexibility and protecting against worst-case scenarios with XHTML and CSS. It’s by the guy who runs SimpleBits.com and has a few major sites under his belt. Some of the ideas are ones I haven’t heard mentioned before (which came as a surprise) and everything so far has been useful. Here’s a few tips and topics it discusses:

• Setting a font size in the body tag, then setting the font size a percentage of that font everywhere else, allowing the entire page to scale equally
• Never defining height for anything, ever
• Using DL/DT/DD tags for more than just definition lists
• Tab based navigation
• Rounded corners for boxes
• Lots of general style and color tips in every section
• There’s a <caption> tag for tables? Who knew?
• Standard complaint ways to format data tables with css
• Getting columns equal length using pure css without tables

None of this was completely new, but the way it was written was a little different than previous books and tutorials. Most tutorials start out with some base HTML that isn’t changed, but the css is styled as needed. Usually when developing it’s more back and forth — you’ll add a class as you need it or realize you need a wrapper div, and that’s how the book is written, by going back and forth between the css and html. Sometimes this means the screenshot at some stage is ugly and incomplete, but since that’s how all my sites are it’s not a bad step to go through.

This is one book that although I read over a year ago, very often ends up on my desk. Although I’m no designer, and sometimes it’s a painful process for me to get something looking the way I want it, the tips in this book are extremely useful best practices. The “Bulletproof” title is well worth it. The idea is that your pages should all be bulletproof — they should work in any sized browser, should be able to be changed with minimal effort and work across the browsers. The book does a good job of explaining why each of the practices employed are bulletproof as well. I’d consider it a must read CSS if there was ever one, and a much better read for programmers than any other css books I’ve read.