Archive

Posts Tagged ‘method’

My life as a CF developer

June 20, 2008 Leave a comment

I am currently employed as web application developer at the Academy for Educational Develoment(AED) in Washington, DC.  AED uses Fusebox 4.1 for its ColdFusion development.  I was familiar with Fusebox, having toyed with it a few years ago back in Fusebox 3, so I wasn’t coming in totally cold, but pretty close.  During my first week, I did a lot of reading due to the fact that my laptop had not arrived; I was hired right after the holidays and things moved much faster than their normal hiring process with the exception of the equipment.

Now that I’ve had 6 months to get used to it and use it at least two different ways, I can confidently say that I like this framework.  We do not use Fusebox in an OO fashion as is becoming a trend these days.  Rather we are still procedural for the most part, but we do use CFCs for most of the newer applications.  I really like using CFCs in my code because it centralizes my queries and business logic.  What I have noticed, however, is that even among the three of us, we have different styles in our use of CFCs, particularly in how we call them.  One likes to use the old fashioned:

<cfset someVariable = path.to.component.method(arguments) />

This is perfectly acceptable and demonstrates a saying I often use in application development.  “There’s always another way to achieve the same task.”  The problem I have with accessing my components in this manner is that it doesn’t explicitly name the arguments as they are in the CFC.  In fact they could actually be different.  Additionally, it seems you have to pay close attention to the order of your arguments as you pass them to the component.  I inherited an application from my coworker and had to add a new argument, but didn’t pay attention to the order in which they were passed.  This resulted in an error in the function that wasn’t obvious at first.  Only after a little troubleshooting did we figure it out.  For this reason, my preferred method of calling my components is:

<cfinvoke component=”#componentName#” method=”methodName” returnvariable=”returnvariableName” argument1=”#argumentName#” argument2=”#argument2#”/>

Perhaps this is a holdover from my hatred of math.  I am very methodical and was never the kid who could skip steps when solving a math problem.  I had to work out each step in order to arrive at the solution.  Using the above method allows me to clearly and precisely state the component and method I am calling, as well as declare each argument I am passing in and naming the variable I will use to refer to the results of that method after execution.  It helps me when writing the act_ or dsp_ file using the data from whatever method to know this information up front.

I mentioned that we do not use CFCs in an object oriented fashion.  We tend to group our CFCs by circuits, usually with once CFC per circuit.  Additionally, it likely we’ll have one Lookup CFC to handle frequently used methods such as querying a lookup table for US States, or Regions, or Countries, or Months, etc.  In this way we can have those methods execute once and be available for whatever page might need them.

Using CFCs in this manner probably is not a best practice.  In fact, probably just the opposite, but it does work for us.  It does, however make for some very long CFCs.  I have a 500 line CFC in my current project.  Thank goodness for the CFC explorer in Eclipse, which makes it ever so easy to jump to a specific method. I have just recently learned about the CF Frameworks explorer in CFEclipse, which I’m finding extremely useful to not only explore the application from a single, outline-style list, but also as a means to help in writing my fuseactions for my circuit files in a slightly more organized way.