My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
I know there is a general disdain for using CFCs to produce the view layer in applications, but I wanted to take the time to explain when I use it: in situations where several customers will be using the same application (hosted on the same server as well).

In my more inept days, long before CFCs were introduced, I just deployed different versions of the same application to the different directories that housed each client's specific version of the application. This was nice because it allowed customization, but of course it became a giant pain having to fix the same bugs in several different places. The same was true if there was an improvement which would benefit everyone.

Eventually, (still before CFCs) I had the idea to just keep a common code base and <cfinclude> the needed files in each client's own directory. I even built the application(s) such that they would <cfinclude> some custom code in spots that required customer-specific computations or outputs. As you might expect, it wasn't long before customers started asking for changes which couldn't be done in the "customer-specific" includes very easily. It became much easier just to write

<cfif customerID is theCustomerRequestingThisChange>
   ... do something ...
   ... do something for everyone else ...

in the middle of the common code rather than do it correctly. Because of the problems with the different versions I mentioned above, I was very reluctant to "branch" clients into differing code bases - so the code became littered with <cfif>'s and got to be a nightmare to maintain.

Finally, along came CFCs. I could have a component and aggregate it into another or inherit from it in another, and only make the changes I needed to those methods which needed it for those clients who needed it. A silver bullet (almost) for all my problems! The werecode was killed!

But, everywhere I look I see everyone telling me not to use HTML in CFCs! So what do you do in the situation where one client's form has to differ slightly from the common code? For instance, you might have a form that has a name section, a contact information section, an address section (or two), and perhaps more. Suppose one client wants to track some other information specific to them, and they want it placed just below the name section and just above the contact information. Do you rewrite the form for that client? While you would be following "best practices," this can lead to similar situations as described above.

I've been placing the common code in CFCs - and with great results. Each section of the form can be its own function, to be called in a main displayForm() function. Then, if a client needs a new section, I simply have to rewrite displayForm() and write the new part of the form. If they need to change the order of some fields within a section, I only have to rewrite that section. Its really helped me cut down on duplicate code and helped me follow the DRY principle.

What do you do in similar situations?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner