ColdFusion admin API CFEclipse snippets

Aaron Lynch has posted some code examples for accessing the ColdFusion Admin Api.  It is often a minor pain to have to go into the admin and turn on/off debugging on your development machine to test certain things.  Additionally in our environment, in order to restart the ColdFusion Server service I have to remote into the server, open up services, and restart.  Being able to open the CFEclipse Scribble Pad, and having quick and dirty access to these things has saved me time already this morning!

So here are a couple of snippets:

[note:  in the examples, the password is set to "coldfusion".  Alter that as you need to.]

  • Restart the ColdFusion Server by typing restart[ctrl][shift][period] and saving/running.  Here is the snippet:
    adminObj = createObject(“component”,”cfide.adminapi.administrator”);
    // Instantiate the serverInstance object.
    myServer = createObject(“component”,”cfide.adminapi.serverInstance”);


  • Turn On/Off debugging by typing debug[ctrl][shift][period].  You are then prompted for enable:true/false.  Then save/run.  Here is the snippet for that one:
    adminObj = createObject(“component”,”cfide.adminapi.administrator”);

    myDebugging = createObject(“component”,”cfide.adminapi.debugging”);

When you go out to his site check out his Flash Paper cheat sheets for all the API pieces.  He put those together using the CFC documenting tool that I blogged about the other day.

No one sitting on the bench in DFW!

I recently put a job posting out to my CFUG for an on-site Jr-Mid level ColdFusion developer in the DFW area and have had no luck at all.   The only responses I have received are either from overqualified developers who were already engaged and just sniffing around, or people out of the area that wanted to work remotely.  Many of the replies on the email list were from other people that had posted jobs previously and were making comments that they too were having a hard time filling spots.   What a different time for ColdFusion developers today than it was a few short years ago!  :)

But as nice as those implications are for us…. I need a developer now!

Forcing your solution on a problem

There is a something that I think many of us are guilty of from time to time. When you become proficient in a particular language or technology, it is very tempting to want to apply your tool of choice to solve whatever problem that comes along, even if a more objective perspective might show that there is a far more appropriate solution.

My Uncle John is in town visiting from New Hampshire, so I stopped at my parents’ house yesterday after work to chat with him for a bit. He and my father have at least 60 years of combined electrical engineering experience, and it is always interesting to me how many parallels there are between the problems and solutions in their industry when compared to the problems and solutions that I experience in software development. My uncle was talking about the problem of choosing the solution before you understand the problem, and how designer engineers often try to force their particular niche into circuitry design, whether it is the right solution or not. Obviously as a programmer I have seen the same behavior, and have certainly been guilty of it myself. He told me that when doing presentations, he has often told this story:

“So last night I was on my way out to the parking lot and I came across this guy under the big light out there. He was down on his hands and knees looking around. When I asked what he was doing, he told me that he had dropped his keys and was looking for them. Having a few extra minutes I figured I would help out so I asked him ‘OK, how big of a radius are we looking in here?’ while spreading my arms out in the area he was looking. The guy looked up kind of perplexed and said ‘No, the keys are over there…’ pointing across the lot ‘… but the light is much better over here’.”

It didn’t matter what the problem was. The guy had his solution whether it fit or not. I think it is healthy for us to remind ourselves not to fall in that trap.

Frameworks are too complex and there is no benefit

Well,  if you have ever spoken to me or read anything I have written, I hope you know that I don’t believe this.  But here is the situation…

We have a developer in our company that dabbled in CF5, but now writes in .Net.   She doesn’t follow any of the current articles/blogs/etc about ColdFusion and her coding style when it  comes to ColdFusion is very procedurally oriented.  The owner of our company has expressed interest in engaging her in some of our current projects.  My manager wanted me to compile some pieces of information for her to read and study so that she can get up to speed in some of the current stuff happening in our world.  Our newest applications are being written in Mach-II, so we wanted her to have an understanding of why we use them and the benefits they present.   I gave her some email lists,, MXNA,, and gave her a copy of Hal Helm’s presentation on Mach-II that he gave to the KCCFUG.

After spending some time reading she told my manager (loosely quoted)

“Frameworks seem to be complex, add difficulty, and don’t really offer benefits”.

While I was reeling from this response, I started spouting my usual rhetoric about standards, organization of code, like mindsets among teams, ease of maintenance, etc…   However, I was realizing as I was talking that even *I* am tired of hearing myself talk about it, and I am sure my coworkers are as well.  I think it might help if she heard come comments from other developers, and it might actually mean more.    If you have a moment, I would love to collect some thoughts in the comments about how (or even why not) a development team can benefit by using a framework such as Mach-II, Model Glue, or Fusebox.

EDIT: I was unable to port my comments from my old blog into the current blog.  However, I thought that I should go ahead and post them into this entry as there was a spirited discussion.  Here they are:

I have a couple good ones:

“Frameworks are a hinderance to quick development, and result in spaghetti code.”

“I don’t like using other frameworks, so I just created my own. “[yeah right]

I will try to think of some more golden nuggets of ignorance. This could get funny.


posted 1684 days ago
Add Comment Reply to: this comment OR this thread

Rob Cameron said:
* Note, I consider the “average” ColdFusion developer to mean someone who didn’t go to college for computer programming and adopted CF because they were familiar with HTML and heard that CF was the easiest way to begin developing dynamic sites.

I agree with her that for the “average” CF developer, frameworks are extremely confusing. The majority of them are an academic solution to the problem of procedural code. If you are one of those academic CF developers it’s tough to put yourself in the mind set of someone who isn’t – explain to me the benefit of looking through a 200-line XML file to figure out how my own application works? What the hell is a factory, DAO or gateway? How is any of this going to make my life easier? I think most developers are just jumping on the bandwagon and not really looking at a framework critically, thinking about how it will actually benefit them. They’re doing it because everyone else is doing it.

(Continued in next post)

posted 1684 days ago
Add Comment Reply to: this comment OR this thread

Rob Cameron said:
Check out ColdFusion on Wheels, I made it specifically to address these issues. I consider it “the framework for the rest of us.”

If she doesn’t mind, could you give me her email address? I’d be happy to have this discussion with her and talk about the reasons she doesn’t think frameworks are for her.

P.S. Why are these comments limited to only 1000 characters? You’re killin’ me! :)

posted 1684 days ago
Add Comment Reply to: this comment OR this thread

JesterXL said:
Part 1 of 2

For projects small in scope, I agree with her. They do nothing but get in the way.

For larger projects that are longer than say, 2 weeks to create, design, and develop, yes, frameworks are a near must.

Their benefits are definately not immediately apparent. For example, Cairngorm in Flex or ARP in Flash… you write like 20 classes with at least 40 lines of code each JUST to get a Button click to load data from a CF page? Dude, I could do that in 12 lines of code and NO classes.

… the benefit comes 4 months later, when your project adds an entirely new section. Attaching that on is cake and does not negtively affect existing code. More so, you can utilize what you have already written vs. writing the same stuff again.

posted 1684 days ago
Add Comment Reply to: this comment OR this thread

JesterXL said:
Part 2 of 2

You know EXACTLY what to write, and WHERE to write it. Each framework I’ve seen, CF, Flex, Ruby, whatever, clearly delineates responsbility of who does what, and where. There is no question, no doubt, you just write code. You’re productive. Communication between developers is more clear because you both know what part works and where to find it. If you both know Mach-2, you immediately know generally how the application works, whether 2 days into it, seeing it for the first after it’s been in development for a couple of months, or re-visiting it 2 years later for updates.

They are extremely painful at first if you’ve never used them. You’ll constantly question why you have to do all of this work to accomplish so little.

…then, one of the aforementioned benefits will arise, and you’ll have some contrast with the old of how you did things, and go, “Damn… this framework just saved my arse!”

(remove your character limit G!)

posted 1684 days ago
Add Comment Reply to: this comment OR this thread

Considering that both of you had to do 2-part posts, I just altered the default setting… type away. :)

Thanks for the comments.

posted 1684 days ago
Add Comment Reply to: this comment OR this thread

I will admit, that at first glance Mach-II seemed to make a “mountain out of a molehill”, but once you get familiar with what the framework expects developing an app is so much more enjoyable. Add Reactor into the mix and its almost too easy!

IMO, the only way to get past the initial awkwardness, is to make yourself adopt a coding standard (“I will develop this app entirely in Mach-II”)…the learning experience is well worth it.


posted 1684 days ago
Add Comment Reply to: this comment OR this thread

ethan said:
The tough thing is that committing to a framework is a leap of faith. Everyone is telling you how great it is and that it makes maintenance easy. But from my view when i started working with ARP i had a tough go with it(hell, i’m still not great with it). I had to do a lot of reading and made many mistakes to get “a button on screen to load something.” But it is a learning curve that will pay off later, adding stuff, picking up others work that you can drop in etc. But in the end it IS a leap of faith. You don’t see it until your well on your way to the other side and you have tangible results that you can see. just my 2 cents.
posted 1684 days ago
Add Comment Reply to: this comment OR this thread

Sami Hoda said:
There will be more documentation coming on Mach II. INCLUDING MACH II FOR MANAGERS… !!!
posted 1684 days ago
Add Comment Reply to: this comment OR this thread

DannyT said:
Jesse is spot on with his comment about not appreciating it til it saves your arse. I frequently have to stamp my authority on my peers who are big fans of “why do all that when you can just ‘code it’?”.

I find using a standard framework helps immensly when clients/bosses come along with “Can’t you JUST make it do xyz?”. Spaghetti style = “not likely, if i move one of my triple nested if statements we’ve had it”, frameworks = yes. Simple.

posted 1684 days ago
Add Comment Reply to: this comment OR this thread

Michael Traher said:
Frameworks can be daunting at first and there is a strong instinct to ‘do it the way you already understand’. I think most people are converted when they have to go back and make a change or extend a system that was written in a structured way, and frameworks are really just trying to formalise a structured approach.
posted 1683 days ago
Add Comment Reply to: this comment OR this thread

Steve Nelson said:
I’m an avid proponent of Fusebox, but i agree, frameworks are too complex and often don’t add much benefit. I’m especially beginning to lose interest in using using XML for a framework. My desire to learn yet another set of tags is non-existant.

That being said, want to see another framework?! :-)

posted 1683 days ago
Add Comment Reply to: this comment OR this thread

Al Davidson said:
I’m definitely with you on the usefulness of frameworks. When I started at this copmany, because their existing codebase was written in Fusebox, and I already knew Fusebox, I could pick up their code and fix bugs / develop new code straight away – I only had to learn WHAT the application was doing, not HOW it was put together.

I put a much more detailed post about this very subject here :…“>Coding Methodologies Are A Good Thing

posted 1683 days ago
Add Comment Reply to: this comment OR this thread

Jon Clausen said:
Since most of my work is done customizing existing applications, I’m a bit late to the party in learning any of the frameworks. Since I’ve been “shopping” them lately to determine which one I wanted to base an entirely new application on, I can very much emphasize with your colleague.

IMHO, what makes frameworks appear so complex initially is that much of the documentation and examples highlight the functions of the framework as opposed to the document and template relationships. Because the developers of the frameworks themselves spent a great deal of time creating those functions, it’s natural that they would wish to highlight all of their possibilities.

The problem with this, though, is that getting started with a framework is really all about understanding those relationships. How does my presentation layer connect to my business logic and, if I choose to use Reactor, how does my business logic interact with my database? Where is the benefit in maintaining the relationships between all of these different files and breaking out all of that code separately? How is that easier than keeping that code all together where I can easily scan down the page to understand what’s happening?

It took me three “Hello World’s” and six different demo apps from three separate frameworks to really start to grasp those relationships and envision how the structure might benefit me and my own application.

Once I really grasped how those pieces all interacted with each other, though, I was sold. Planning and developing an application from scratch (I chose to use Model Glue) becomes much easier since the very structure of the framework requires a methodical approach in which code is written first. I’m not an expert by any means and there are moments when I get very frustrated with the restraints imposed on me by the framework. In the end, though, I am finding myself a convert to the framework cause.

posted 1683 days ago
Add Comment Reply to: this comment OR this thread

Ali said:
I’m a proponent of frameworks, having both worked with and without them.

Like most other coldfusion developers, I started out without any framework. For several years, I worked on horrible spaghetti code, includes within includes within custom tags.

However coming from a computer science background and working with other developers with similar experience, once we got to an advanced level of proficiency with the language, a framework just seemed like a natural progression.

I think it separates an advanced, mid to senior level developer from a novice.

Before fusebox 2.0, I had already started gravitating to an organization of my code into certain folders, and organizing the includes etc. Most other developers who were above novice level who I had the pleasure of working with did the same.

Then when I finally started taking a look at Fusebox, it made sense because of the years of coding off the seat of my pants, etc, had already led me to a desire to organize my code in a way that was easy to maintain for myself as well as others.

The only hurdle I see for current fusebox is the xml structure, which to me is trivial. Most mid to advanced developers I have worked with who aren’t proponents of frameworks understand xml structure, and when I show them a fusebox.xml file, they like how they can immediately see the flow of the application structure.

So I hope this doesn’t sound patronizing or condescending to your coworker….

But what I’m trying to say is that frameworks or some sort of organization makes sense if you are a successful experienced developer.

As for Mach-II, I think that’s hard for anyone.
The big hurdle in that though is selling the person on OO methodology. That again goes back to my idea that, that shows the lack of experience of the developer. I’m no OO guru myself, so the same things apply to myself also. I ran the other way, the first time I took a look at Mach-II. But since I learned OO as part of my college coursework, it slowly started to make sense, and I did my own research on OO patterns etc, to refresh my memory.

However, I do believe that again, having an xml file should not be the detractor. I think if an experienced developer shrieks at the site of the xml file, then they have other problems. It’s something most experienced developers should have a handle on already.

The fact that you have other developers on board with Mach-II is a great plus on your side.

posted 1683 days ago
Add Comment Reply to: this comment OR this thread

Adam Ness said:
I actually have to agree with her on this count. I’ve been developing “cowboy” code since CF3, and I’ve tried on various iterations of Fusebox for size, and generally found that the applications I wrote using Fusebox took longer than they would have with cowboy code, took longer to debug because errors were showing up in places that were heavily obscured, and were a lot harder to maintain, because adding something to one fuse ended up requiring changing five other fuses, which required changing 25 other fuses, and so on, and so forth.

I can’t comment on any Fusebox after 3, since I gave up on it at that point, and I can’t comment on any of the OO frameworks, because their reliance on CFObject instead of the more security-friendly CFINVOKE syntax makes them unuseable in my hosting environment.

posted 1683 days ago
Add Comment Reply to: this comment OR this thread

John Farrar said:
Hammers offer benfits, but not when you need a screw driver! And a flat head won’t help when you need a phillips either.

Frameworks can be like toolboxes and they can also be sequences and styles of building houses. How do you lay the foundation, and then build the building on top. Yet, for different types of buildings you will find different frameworks and different building tools are better than others. The modern framworks are not for beginners and certainly (though not admittedly by the ‘devout’) not appropriate for every solution.


John Farrar

posted 1667 days ago

Converting ColdFusion Arrays to Java Iterators

I have been working with Reactor for several months now and have grown fond of using iterators as collections of children objects.  I never looked at the voodoo magic under the covers that makes that happen in the Reactor core files, but with a little playing around and testing today I realized it might not be so magic afterall.  I created a CFC that accepted an array as an argument, then returned that array’s iterator() method.   It is plainly obvious by looking at the code, but I just never knew you could do this.  For anyone interested, here is the source of my test:


<cfcomponent name=”IteratorTest” hint=”I test iterator stuff”>
<cffunction name=”init”>
<cfreturn this />

<cffunction name=”returnIterator” returntype=”any”>
<cfargument name=”MyArray” type=”array” required=”true” />
<cfreturn arguments.MyArray.iterator() />

IteratorTest = CreateObject(“component”,”IteratorTest”).init();
MyArray = ArrayNew(1);
MyArray[1] = “one”;
MyArray[2] = “two”;
MyArray[3] = “three”;

<cfdump var=#MyArray# />

<cfset MyIterator = IteratorTest.returnIterator(MyArray) />
<cfdump var=#MyIterator# />

<cfloop condition=#MyIterator.hasNext()#>
<cfset thisItem = />
<cfoutput>#thisItem#<br /></cfoutput>

EDIT: useful comment from Mark Mandel on the matter:

I like this way of looping around arrays, but you can also do the same thing with Structs, but it just takes a little bit more work:

iterator = myStruct.values().iterator();

It should be noted that iterators for both Structs (Hashtables) and Arrays (Vectors) are ‘fail-fast’ – which means if someone removes and object from the array/struct not through that iterator, an exception will be thrown.

It may be worth making a top level copy of the array before returning the iterator to avoid collisions like these.

Subclassing Data Access Objects for Flexible Apps

I am giving a presentation to my CFUG tonight demonstrating a method of writing your code in a way that will support multiple data persistence methods.  In the example code, there is a mini-app that adds/edits/deletes addresses from the following storage methods:  1) MSSQL using Stored Procs, 2) MySQL using straight SQL, and 3) encrypted WDDX text files.  The approach uses subclasses of the AddressDao and AddressGateway that are specific to the type of storage.    Below is the blurb from the site:

Dave Shuck: Subclassing Data Components for Flexible Applications

One of the advantages that you hear repeatedly of a good OO design, using DAO and Gateway patterns is the database abstraction. One benefit of database abstraction is that your application is not tied to a specific database architecture. This means that if you suddenly need to uproot your site and move to a different database, you do not have countless queries buried throughout your code. If you followed the rules and followed the patterns, then you simply need to alter the code that persists your data in the DAO and Gateway objects. But what if you are building an application that you know will sit on several different databases or use different methods for data persistence? One method would be to create subclasses of your DAOs and Gateways that deal with specific persistence needs. I will be showing a simple example mini-application I wrote that will demonstrate how the database has a somewhat insignificant role in an OO system. We will be running the same code on top of three data persistence methods: 1) MS SQL with stored procedures, 2) MySQL with plain SQL, and 3) Encrypted WDDX text files (Why? Because we can!).

Project:Unity from CFEclipse!

I am sitting in the CFEclipse session by Mark Drew and he has just announced a COOL new feature!

Project:Unity is a new feature in CFEclipse that allows you to browse an outline view of almost all ColdFusion framework XML files including MachII, Model Glue, Fusebox, ColdSpring, Transfer, Reactor (and maybe others that I missed!)

As you click down through the human-view and you select an element, it opens the config file and goes directly to that node. Even in the case of Fusebox with nested XML files (circuits) it actually opens the correct file and goes to the correct spot.

You can also right-click and add elements appropriately from the outline view. There are contectual drop-down menus that guide on adding new elements. This is SWEET!

This is also extremely configurable and makes for easy extensibility to add what you need or even create what you need for your own framework!

Awesome Mark!

But…. what am I going to do with all these snippets?