Coldfusion CFC Do's and don't's
There are a lot of articles around about coldfusion components; doing a Google search for the term "coldfusion components" brought back just over 160,000 results, that's an awful lot of information to
digest. I also found Rob Brooks write up on O'Reilly called "Top Ten Tips for Developing Coldfusion Components" written back in 2003 and found it covered a lot of good stuff thats still valid today.
I would, however, like to add a few of my own tips as well as some don't's. It's highly likely that with all those results from Google I'm writing nothing new but I think an occasional review is always good.
No Place for Sessions
Coldfusion components are no place for session scoped variables. I see it time and time again and in my opinion it's pure laziness! By putting session scoped variables inside of your component you are coupling your component to the existence of that variable in the session scope. The argument I often hear is "the session will always exist before the method is called". Sure the session will always exist, but will the variable inside the session exist? If you need a variable stored in the session then pass the argument as a variable, which brings me to my next point.Use Arguments
I understand that typing all those cfarguments can be a bit time consuming and tedious, and I often see components written without any arguments specified at all, or with the entire Form scope passed as the single argument. I'm not a big fan of this and tend to discourage it's practice. The eclipse RDS CRUD wizard can cut a lot of this time consuming and tedious work out for you and I often start with the auto-generated components and flesh them out from there.
The CFProperty Tag
So what is cfproperty tag and whats it used for anyway? The cfproperty tag defines the properties of a component, for example person.cfc will probably have FirstName, LastName, as two of its properties. But if your component is not going to be exposed as a web-service you really don't need to define properties using the cfproperty tag. The good thing is, however, that if you use the eclipse RDS CRUD wizards to build your components from the database it adds the properties in for you automatically, and you gain some meta data for component introspection with the getMetaData() method.
Using the cfproperty tag doesn't define or initialize variables for you, you still need to to that yourself. I typically do that in a cfscript block at the top of the component, this ensures that the component variables are set to their default values each time the component is invoked. Other people place the initialization code inside the init() function, still others call the init() function just after the cfscript block providing an "implicit" initialization.
<cfcomponent output=false displayname="person">
<cfscript>
variables.id = 0;
variables.firstName = "";
variables.lastName ="";
...
..
</cfscript>
<cffunction name="init" output="false" returntype="person">
<cfreturn this/>
</cffunction>
Reuse your CFC's
Components were introduced into CFML for a reason and that was/is to provide developers with the ability to structure and reuse code effectively.If you are going to build something build it in a way that promotes reuse that way you don't have to build it over and over. The extends attribute is a perfect example of providing a mechanism for code reuse if you previously built a user.cfc but you need a few more properties you can extend the existing one to include the properties instead of creating yet another user component.
But it is something that requires a bit of planning.
To DAO or not to DAO
This question requires a bit of "big" thinking. If you are a SQL Server shop and your application will never run on anything but SQL server then do you really need to create all those DAO's for each of your components? I myself am of two minds on this topic. On one hand it does create a bit more overhead but on the other hand all your database access is neatly separated from your business logic. I also find that the larger the project the more sense it makes to separate the data access. If your project has even a slight chance of being rolled out onto other databases then it is, in my opinion, a no-brainer, go with DAO's!
Organize Organize Organize
I can't stress organizing your components enough. If you have a component centric application it's doing you no good to have hundreds of components all in one directory! I generally package my components starting with the com directory, then (perhaps out of vanity) my next folder is gg that basically defines my namespace where components that I write are stored, but it can easily be a short name for the application. I then further sub-divide my components into logical folders that signify their use com.gg.user etc. It makes it a heck of a lot easier to find the component you are looking for if they are not all lumped together.
Happy Coding...
Subscribe
Subscribe via RSS
Follow me on Twitter
Or, Receive daily updates via email.
Tags
adobe air ajax apple cf community cfml coldfusion examples ext flash flex google javascript jquery max2007 max2008 misc open source programming railo software technology ui
Recent Entries
No recent entries.
Blogroll
An Architect's View
CFSilence
Rey Bango
TalkingTree
Wish List
I am not a big fan of the CFProperty tag. I see that it has to do with properties, but how do those properties overlap with the getters of an object. For example, if I have a Contact object that FirstName and LastName, but I have a method GetFullName()... do I have to have a FullName CFproperty tag? The GetFullName() is encapsulating the logic of combining properties, but is it in itself a property?
I guess because the use of these was always a bit of a mystery, I never used them (that I don't have many remote calls yet in my applications).
One thing I force myself to keep in mind is var scoping. I use to never do this until I met Mike (creator of varScoper).
As a matter of fact. Mike just posted a wonderful example on what could happen if you don't var scope properly. See it here on his blog:
http://www.schierberl.com/cfblog/index.cfm/2008/7/...
http://www.garyrgilbert.com/blog/index.cfm/2008/7/....
Its kind of scary. We use var scoper at work but not nearly enough and not often enough :)
Every little bit help in regards to getting an understanding about var scoping. It amazes me sometimes how developers can put var scoping on the back burner instead of taking the 10-15 seconds to var scope a given variable. It's kind of like the "until it really effects me and my app I am just going to leave it alone". Ya know?
Your example is a great one. I was at a Saccfug meeting (Sacramento) just recently and many people did not know that you need to var scope variable that pertain to certain functions in cf (loops, etc).
As far as I understand properties they are the things that describe an object (firstname,lastname) and while each property typically has a getter and a setter associated to it that doesn't prevent you from adding methods that combine properties to fulfill business logic. But fullname is not a property of the person object it is a composite made up of two properties. I wouldn't have a fullname property, I may have a getFullName() method but I wouldnt have a setFullName() method
That raises an interesting point then; if you cannot directly access properties as they are generally private properties and can only be accessed via methods calls.... does it really help anyone to know the properties of an object? What if an object has 20 properties, but only 3 of them have remote access methods?
Take your firstname, lastname, fullname example. You 'could' have full name as a property of the object but only create a public getter for it making it read only, in order to change the fullname you would have to set either the firstname or lastname.
I was a little bit vague on the cfproperty use with web-services. If you are going to be returning a complex datatype in a webservice you can create an empty component that contains just cfproperty tags that describes a complex data type, you can then set the returntype of a remote method as that component.
something like this:
<code>
<cfcomponent displayname="messageResponse" output="false">
<cfproperty name="Status" type="numeric">
<cfproperty name="Messages" type="message[]">
</cfcomponent>
<cfcomponent displayname="message" output="false">
<cfproperty name="messageName" type="string">
<cfproperty name="messageBody" typ="string">
</cfcomponent>
</code>
Then in the returntype we have returntype="messageResponse".
outside of this use it's good for introspection and selfdocumenting..and thats about it :)