Wrong ColdFusion Religion
This is a realization that has been thrust upon me over the years. I belong to the wrong ColdFusion religion. My religion is that ColdFusion was designed for clean, understandable applications written in a quick and easy style by people of all levels of programming skills. This is NOT the current religion of Frameworks and OOP.
I was burnt a while back when daring to suggest that a framework could be altered to fit a client. I see that I was right then and I feel I'm still right now. I'll use a framework when it's required and will only use parts when they're required. I'll use OOP when it's required and only parts when they're required. I'm not going to accept the dogma that says that frameworks and OOP are the one, true way to go.
And the new golden child, ORM? Well I'll use it when it looks right for a project and reject it when not. And when (not if) this opinion gets people upset, well...too bad.
Yes, the above is a rant and one that's been sitting in reserve for years. It was true then and is even more true now.
From a developer viewpoint, every program I've seen (that wasn't written by an expert) that didn't use a framework was a brittle, opaque "ball of mud" that was difficult to understand, modify or enhance. Lots of nested cfincludes, copied and pasted repeated code, and unscoped variables. No thanks.
Just know when "to" and when "not to".
I've always believed in using the right tool for the job - not all screwdrivers were created equally! B->
</cliff>
The problem comes when that one page grows to 100 and you have to explain refactoring to the client. "Whats this refactoring crap, the site has worked fine until now, except it seems to take longer and longer to do simple changes, stupid nerds don't seem to know what they're doing .."
The best argument for not using OOP or MVC that I've heard is "billing by the hour..."
"This CT takes 4 parameters, like so: <cf_getIPAddress subnetcode=”encr” vlan=”1? compsub=”1? comptype=”5?>. Using these 4 parameters, the CT will return the IP address of the component, along with any component-specific labels (such as a prefix of ‘Virtual’ for certain components). The problem is that I have to put this code snippet into 30 different files, with a total number of 1,116 insertions! That in itself is a lot of work, but when you consider that for each of these I also have to update a DB table (as one of the parameters isn’t currently recorded), insert the CT code, check and update the four parameters, save, upload and test, the task grows exponentially. It’s taking about 2 minutes per insertion, so by my reckoning, it’s going to take about 37 hours to complete what my boss and I both thought was going to be a fairly simple task. I wonder how long it will actually take? I’ll report back when I know."
Dude, WTF? If you ever have to modify that, you're screwed.
Frankly, frameworks are a massive performance hit to any application. I don't care what anyone argues, I've experienced it. I've seen an app converted to use a simple DI framework and perform 500% slower. The mindset that CF developers have, and many other developers, that CPU and memory are cheap is not the right mindset. If I have to spend $35k to run the same app I can run for $5k there is an issue, and that extra $30k is NOT saved in development. Frankly, framework-based projects often are many times more expensive to develop than non-framework apps. And in the end, was it really needed? In the 10-12 year life (if that) of that app, how much really changed?
For many of the simple, one-off apps that the majority of CF developers create, frameworks are a waste. Contrary to popular belief, there is a HUGE majority of folks who never have need of a framework. I also believe frameworks make lazy developers.
This being said, I do believe there are many cases for frameworks. I've taken to them for a few of my projects and have seen the benefits. But still, I don't believe that for 70+% of the apps I have built that a framework was a worthwhile investment.
Ahh! The delights of supporting an application built on CF 5! B->
Yes, I'm in that unhappy place at the moment! No OOP for me at the moment - Pre-CFC baby!
</cliff>
Yeah , I recently was offered a job; the first thing the recruiter told me was it was CF 5 with no upgrade forseen. I politely declined and the recruiter said "yeah thats what everyone says, I'm having a hard time filling this position."
So can't say I feel your pain, but that would sux0r.
There's certainly nothing wrong with OOP/Frameworks, but there's nothing wrong with CF 5-like development either. It's a matter of knowing when/where they're needed.
In Macromdia/Adobe's push to sell CF as an enterprise platform, they've lost many of us in government, education, non-profits. CF has been used in these areas because it was easy to pickup by all level of developers. With some training and some time, you could build something useful.
Anyhow, Aaron's comment of knowing when to and when not to is correct.
If your site can grow to 100+ pages, you should have planned to use the right tool. If your making three pages, a FW may be overkill. As a general rule, I use CFCs and frameworks for my projects. But, I've strayed from time to time for simple projects.
Thanks for taking the time to respond.
i use frameworks and cfcs, but having recently taken over an old school site,
there is defiantly something rather RAD about the old skool approach
I am really really over reloading frameworks every single f^^&^k cfc change
at least some frameworks haved moved away from MVC(XXXXXMMMMLLLLL) CFML is far more powerful than XML! autowiring all the way, the XML oft violates the DRY principle
To be honest, if the market wasn't as depressed as it is in the UK and if this contract in Brussels didn't pay so well, I may not have taken it, but as a professional developer, you have to keep putting bread on the table - it doesn't really matter which tools you use, at the end of the day.
I think the consensus is that this isn't a right or wrong discussion.
</cliff>
Hell, in one of my last gigs as an independent I wrote the app as procedural in Fusebox because Fusebox fit the job well and let me put the app together _fast_. You really don't give any detail about how you were "burned" or the actual details of how "a framework could be altered to fit a client", but if you were suggesting to change core files and put a nonstandard version of a framework into production... well, you were playing with matches, and everyone knows that if you play with matches you get burned.
The whole reason one runs a framework in the first place is standardization, ease of upgrades, a common language across a developer base and a whole bunch of other things that count on the framework being consistent. Changing it (depending on how or at what level you're changing it, anyway) is almost always A Very Bad Idea (tm)). On the other hand, with, for example, Model-Glue, you have the option of overriding framework components at the application level and using ColdSpring to make it work... so you can implement your own versions of core files without actually touching the framework itself. Then again, even doing that isn't (generally) changing the basic nature of the framework so much as tweaking specific details to your own advantage. Case in point, I have a custom extended MG controller that adds logging to makeEventBean(), so you can take a peek at what your controller is finding as it goes about doing what it's supposed to do.
I think the only concepts that anyone would harp on are encapsulation and loose coupling which are key concepts in any, ANY, programming situation... except where they're not.
The _only_ thing that matters is to know what you're doing and why. Not using a framework? Why not? "I'm not using CFCs in this project" is a perfectly fine statement, as long as you have a decent answer for the question "Why not?" In the project I mentioned above, it was because other devs would have to support it AND it had to go together fast, so procedural was the primary choice. Fusebox gave me a way to reuse their existing codebase with very minor changes (and a very flexible end product at that) and a very robust request-processing platform, allowing me to simply focus on the data and the display.