I Just Contributed CFExecute to CFScript-Community-Components

A few weeks back, Adam Tuttle posted about his new project to get CFScript service CFCs created for all of the appropriate missing tags. It’s a great project, I tweeted about it. So did others. But I wanted to do more. So today I made a contribution. I added CFExecute support for CFScript.

It’s a pretty mundane thing to add, and it took me about an hour from start to finish. All I had to do was:

  • Fork the CFScript-Community-Components to my github account.
  • Clone it to my Mac
  • Write the code.
  • Push changes back to my repository.
  • Make a pull request for my changes to be added back to CFScript-Community-Components.

That might sound like a lot, but I did it entirely within one hour. It was a great learning experience as I had never forked and pull requested someone’s project before. That being said I couldn’t have done it without GitHub for Mac, which I highly recommend.



ColdFusion Builder Extension Using Flex

So, buried in the documentation around ColdFusion Builder is the fact that you can write extensions in Flex. I decided to fool around with this for a bit.

If you want to skip all of the demo and explanation and just try it out, feel free to pull down the extension:

Builder Stats at RIAForge


Builder Stats – ColdFusion Extension with Flex from Terry Ryan on Vimeo.


So doing it is pretty easy on the Builder side:

  • Create a remote service CFC for all of the information that you want to expose to Flex
  • Have your ColdFusion Builder extension pass information to the Flex generated SWF
    • Pass any variables to the SWF just like you would pass URL variables

On the Flex side:

  • Pull in the remote service cfc as a WSDL* using Flash Builder’s Data/Services
  • Write your Flex app to use the services that get created
  • Alter the generated ActionScript classes to use a WSDL that is passed into the SWF via the URL (Flash Params)

One more thing:

I’m not sure if this is a Flex thing, a ColdFusion thing, an OS thing, a webservices thing, or a me being dumb thing, but the automatically generated WSDL for my remote service CFC was different on Windows and Mac. Consequently the SWF could call the Mac hosted WSDL but not the Windows hosts WSDL. My solution? Create a static WSDL file that had the service spelled both ways. Maybe a hack but worked like charm.

Anyway, if you want to see the code, it’s available on github:

*WSDL? Why not Flash Remoting (or ColdFusion in the Data/Services list)? Remoting needs to be configured to each system’s configuration, and isn’t very discoverable. WSDL doesn’t require knowing about the Extension user’s AMF setup; it just uses a URL, which can be easily discovered.


ColdFusion 9, Mango Blog, and git

I made a few major changes to my site in one fell swoop.

A few people asked me questions about the changes so I figured I would explain.

Why a VPS?

I really like my hosting company, YoHost, but it was still shared hosting. That meant I couldn’t experiment with administrative settings and whatnot. Also I was constrained to my hosting provider’s upgrade schedule. Changing to a VPS meant that I can do whatever I want whenever I want. I like that freedom.

Why ColdFusion 9?

You mean other than that I am an evangelist for it? Well I actually used a few pieces of it. I built an admin piece for my events page using ORM and ColdFusion Builder’s code generation. I also added a page that pulls in my presentations from SlideSix. To not tax their servers too much, I used the new caching features of ColdFusion. So I’m not just using ColdFusion 9 to use it, I’m leveraging some of the features.

Why Mango Blog?

First off let me just say, I love Ray Camden. I’d go so far as to say I have a non-sexual man-crush on him. That being said, I went to Mango Blog. I’ve been using it in our internal blog that Ben talked about a while back. There are a few things that I completely love. I love the rich text editor. I love the plugin architecture. I love the caching. I love the skinning. It’s fantastic. Those were my big motivators. I felt that even with the changes I made to the default Mango Blog install I could easily keep it up to date, whereas I felt extreme apprehension about updating BlogCFC because of all of the changes I made to code to make it work the way I wanted. To be clear, I had to tweak both, it’s just that my Mango tweaks were mostly in a skin, which won’t get changed by future updates.

Why git?

Because I want to be one of the cool kids who’s all like “Subversion, oh yeah I did that like 8 years ago, I feel so bad for you for using a mature technology that you can rely on.”

Okay maybe not. The big motivator for me for git was online/offline changes. I often work without a good network connection. Being able to work properly, with multiple check ins even without connectivity was killer. I also appreciate the fact that the metadata is in one place. This makes copying the project during a build feasible instead of a network intensive svn export. This reduced my build process for my site from 3 or so minutes to 30 seconds. This means I’m more likely to update more often.

So there you go. This was a very practical upgrade for me, I got a lot out of it, and I have a few reports that the site is even faster then it was before. So except for a little blog barfing on the aggregators it seemingly went well.