ColdFusion Frameworks Exclusively Have Maintainable Code?

Have you checked out ColdFusion on Wheels yet?? http://www.cfwheels.com I consider it to be "the framework for the rest of us." Mach-II, Model-Glue and them seem way too academic for a "normal" CF programmer -- someone who started with CF because it was easy to develop things quickly. While Wheels relies on OO stuff behind the scenes to keep everything organized, you don't need to worry about it too much yourself, you just get to write code and have fun! There are a couple of good video tutorials on there and some written docs as well. 0.5 will hopefully be out this week with everyone's favorite feature, scaffolding!

I think its fair to say that an advanced programmer will have some of methodology. Code developed with a methodology is generally much easier to maintain than without.

Now, whether an advanced programmer knows they use a methodology is another question. Some may not because they may not look for it, may not care enough, whatever it is I bet they use one though.

Frameworks are really just methodologies taken to the next level with some functions automated by code.

Some of you are commenting about off topic (close but the target but your on a tangent conversation to the focus of the post). His point was that it doesn't take a framwork that is layed out as a framework to be good code.

Good post,

I personally wouldn't touch a framework for the following reasons.

1. There is nothing you can't achieve with CFC's alone
2. Adobe might release more OO features in V8
3. There is no guarentee of ongoing support of these frameworks.

In developing real world commercial applications, I prefer to rely on what Adobe give me.

Not really, have you looked at all the "living dead" projects on SourceForge recently?

The benefit of open source is that you have access to the code, so if everyone else in the world moves onto something else, YOU can still maintain and develop the code. This still gives you the benefit of other peoples code to get started, but none of the benefits of ongoing input from others.

If you're a community framework kind of person, you'll probably find yourself porting active sites to new frameworks or versions of frameworks every 3-5 years (guestimate).

Since we're firmly on the the topic of framework vs. non-framework, which as John pointed out wasn't my original intent with this post, I'll add another point. :)

Say you develop a large site with a framework. Later you find out the framework now has some important bug fixes, and some cool new features. How easy is it to upgrade?

This is a problem I have with this blog. While I really like BlogCFC, every time Ray puts out an upgrade I've got a largish job ahead of me to upgrade my blog. You can't just throw the new core files in and run with it, there's the blog layout files, integrating code tweaks, not to mention DB updates (the latter is not a problem with the frameworks).

I know the framework developers probably try to maintain backwards compatibility, but as with all software, if you're going to move forward, you've got to make changes that will affect previous versions.

Second sentence should read:

"Just because members of one set (framework-based applications) are members of another (maintainable application), nothing prevents members of a third set (non-framework applications) from being part of the second (maintainable applications)."

These threads are always stimulating and mildly or overtly controvertial. I have spent the past 7 years traveling the world helping mainly ColdFusion and some JRun users to find and fix application perormance issues. If I can pick up what is going on in the code more quickly, the client benefits. Whilst it is true that a recognized framework does not guarantee good code it is also very true that a properly used recognized framework instills a recognized order into application development across disparate clients. I have not found nor can think of any valid points as to why recognized frameworks should not be used in coding all web applications.

> You will see this post as a 'troll' because you are
> firmly in the frameworks camp, purely by nature of
> being a framework author.

I'm not sure it's a good idea to state another person's reasoning unless you're a mindreader. I saw at as a "troll" post purely because it used a controversial headline that was founded on a logical fallacy.

According to your logic, a person stating that frameworks make applications more maintainable means that they also believe that no non-framework application is maintainable. That's simply a boolean error any programmer with her/his salt can spot. It's like saying that because all Oranges are Fruits no Apples can be Fruits, and I take offense to it: I'm obviously a big fan of frameworks, but I think it's perfectly possible to write a maintainable app without a framework. It's just more difficult to do so.

Barney's quote on CF-Talk ("I can make any FB application have better performance characteristics by ripping out the FB. I just won't be able to modify it tomorrow with any sort of effectiveness...") concerned framework overhead and performance. His point was that by throwing out the framework, you'd get fractionally better performance (FB is faaaaast) at the expense of modularity and maintainability. That's just common sense. He's not making a claim that "you have to use Fusebox in order to have maintainable code."

> In your comment you said, "It's a lot harder to have
> both the experience and maturity to recognize problems
> with the specific portions of your own application (
> like flow of control or dependency resolution) where
> frameworks can help." This comment is similar to the
> above, because you are saying that people that don't
> use frameworks have a hard time achieving the level that
> frameworks give you.

"Achieving the level?" I'm not sure what you mean here, and I'm not certain you understood what I said. I'm certainly not saying that people who don't use frameworks can't achieve high levels of experience and maturity - that's absolutely absurd.

What that statement means, broken down, is that it takes a certain degree of pragmatism combined with software architecure experience to recognize the problem sectors of a given application's architecture, and that it's a lot harder to do that than it is to write CFCs and call them at the top of a page. If I had to sum up what I feel separates an "architect" from a "developer," it's the ability to think in this manner. I've learned this through personal experience - it's common knowledge that I was anti-framework for a long time, and that my apps were nothing but collections of .CFM pages that called CFCs for their business logic.

> it's just as easy for such an experienced coder to
> use their own OO techniques as it is for them to adapt a
> framework.

That's an odd statement. OO techniques are entirely different from frameworks. I'd say it's a *lot harder* to learn good OO than it is to use a framework. Heck, I wrote a framework, and I'm still learning OO. One of Sean's favorite quotes is something like "I've been doing it for twenty years and I'm still learning - it's hard stuff!"

While I happen to be in the "Frameworks are Good" camp, I have observed that some CF developers that are not firmly in the frameworks camp perceive the message from the frameworks guys that they are inferior to their frameworks brethren. While that is definitely not the message, I do think that is how it gets heard by some people.

Brian,

I agree, that is the perception. And with a lot of blog posts out there that talk about skill divides in the CF community, where using a framework is one of the measuring sticks, I think the message is pretty clear. Again, I'm not saying that frameworks are bad, but there is a lot of snobbery coming from the framework camp, particularly in the mailing lists.

I have always had the state of mind to never use frameworks when creating applications. The reason, SPEED. Pick a framework, any framework, I don't which one. I will bet my life that there isn't a framework out there that doesn't decrease (in terms of speed) the loading of the page by at least 4 fold. I've tried several frameworks (I won't say which ones to prevent a flamewar) and all of them have failed in this department. Using them, I saw my page load times jump from 31ms to over 400ms! Doesn't any load test these things before they release them? And if you do, what makes you think that a 400ms load time is acceptable?!?!

Until these frameworks are polished enough to give acceptable load times, I will continue to develope my way: I basically use BEANS, BO, DAO and then one big CFC for the application methods leveraging all classes. This way cuts down on my development time, increasing the enforcement of business rules, increases the speed of page rendering, is maintainable and extensible.

It also sounds like Tony's using ColdFusion debugging to judge load times, which is pretty much a worthless exercise the moment you involve CFCs.

Yes, the frameworks have been load tested. Model-Glue has been load tested extensively. If you'd really like to bet your life that Model-Glue will quadruple your page execution time (or M2, or especially FB), I hope you've made your peace with Dog.

I would have to disagree that Matt and Peter were implying that you can't get that maintainability without a framework.

If I say the benefit of a certain model car is good gas mileage, does that mean other cars don't have good gas mileage. It does mean that compared to the average car, it gets good gas mileage.

Likewise compared to the average application, a frameworked one is easier to maintain. Now that may be an unfair statement because nobody can look at all CF applications and judge their 'ease of maintainability'.

I would say that for a person like myself - who doesn't have a programming background and is a newbie to the OO style - coming up with my own methodology and creating low maintanence components is harder to do on my own versus learning a framework.

I have to say that Tony Petruzzi's coment has to be one of the most comical things I've read all year. It's not that he's so incredibly misinformed about frameworks, it's that he's so confident that he "knows better", like the thousands of CF developers who use frameworks have their heads in the sand and wait 500ms for every page to load thinking in their mind ("oh it's because I used a framework").

Jacob - stop putting words in people's mouths. No one is saying you CAN'T write maintainable code without a standardized framework - people are saying that it's EASIER. The thing EVERYONE needs to realize is that EVERYONE uses frameworks. Either it's a documented, tested, and community-supported one, or it's the one you cooked up on your own. Usually those who cook up their own don't know what they're doing - Tony is a great example - he thinks one class that handles everything is an example of "maintainable" and "extensible" code.

I've been using Fusebox since the beginning. The actual beginning that is, having written the very first Fusebox website almost 10 years ago. I think frameworks are great, i think they have their place in web apps. I also think in the last few years they've gotten so complex they've taken a step backwards. I've tried pretty much every CF framework out there, i still prefer the MVC concepts of Fusebox 4. It's inline with how i picture software in my head. But i'm slowly realizing those MVC concepts can all be done directly with CFCs, without 'core' files and without learning another XML language. Lately that's how i've been building my own apps. But it's hard to argue this new style is more or less maintainable that a fusebox 4 application. It's probably a wash.

In my opinion maintainability comes down to three things

1) indenting code
2) small file sizes
3) how intimate the programmers are with the code

Frameworks help with that third item above.

Wayne, tell me if this is too complex. I've had tunnel vision so maybe it is still too complex...

Your application has 3 top level folders: Controller, Model, View

In your view folder you have subfolders, example: "users". In the Users folder you have 1 cfc: users.cfc and a bunch of display cfm files. The cffunctions in the cfc include one or more cfm. Example function: "LoginForm" that function includes: dsp_LoginForm.cfm

In your model folder you hve subfolders, example: "users". In this Users folder you have 1 cfc: users.cfc and a bunch of QRY/action cfm files. Like the view folder, the cffunctions include one or more cfm files. Example function: "validateLogin" that includes: act_validateLogin.cfm

Finally you have a controller folder with subfolders. example: "Users". In this users folder you have 1 cfc users.cfc and NO cfms. The cffunctions here cfinvoke functions from either model, view or other controller Objects.

controller cfcs only do cfinvokes, model and views only do cfincludes. All 'real' logic/UI code is stored in the cfms. There are a few details with regards to passing data around, but that's about it.

What do you think? Is this still too complex? I can't tell anymore because i'm so used to working like this.

Yeah the controller concept isn't obvious, but it is very powerful. Here are a couple examples. Sure there are lots of different solutions to these problems, but try to see where i'm going with this. Compare these two functions:

<cffunction name="Receipt">
   <cfinvoke component="#application.model.Orders#" method="getOrder" argumentcollection="#arguments#" returnvariable="arguments.getOrder"/>
   <cfinvoke component="#application.view.Orders#" method="ViewReceipt" argumentcollection="#arguments#" returnvariable="arguments.body" />
   <cfinvoke component="#application.view.Layouts#" method="masterLayout" argumentcollection="#arguments#" />
</cffunction>
<cffunction name="PrintableReceipt">
   <cfinvoke component="#application.model.Orders#" method="getOrder" argumentcollection="#arguments#" returnvariable="arguments.getOrder"/>
   <cfinvoke component="#application.view.Orders#" method="ViewReceipt" argumentcollection="#arguments#"/>
</cffunction>

In the first function it calls 3 methods. The first one gets the order from the database (model CFC) and puts that query into #arguments.getOrder#. The second one loops over that query and creates some HTML. Now it doesn't immediately output the HTML to the screen, instead it puts the HTML into a string variable called #arguments.body#. Finally it calls another view template that contains the site layout. That cfoutputs the body variable inside some more html allowing for a nested layout.

Now the second function calls the same first two methods, but it doesn't call the layout method. So with relative ease we can change the UI without changing the original page. Does that sort of make sense?

The same thing can be done with action code. Here's another example:

<cffunction name="editaddress">
   <cfargument name="AddressId"/>
   <cfinvoke component="#application.model.users#" method="getaddress" argumentcollection="#arguments#" returnvariable="arguments.getaddress"/>
   <cfinvoke component="#application.view.users#" method="editaddress" argumentcollection="#arguments#"/>
</cffunction>
<cffunction name="ViewReceipt">
   <cfargument name="BillingAddressId"/>
   <cfargument name="ShippingAddressId"/>
   <cfset arguments.addressId=BillingAddressId>
   <cfinvoke component="#application.model.users#" method="getaddress" argumentcollection="#arguments#" returnvariable="arguments.getShippingAddress"/>
   <cfset arguments.addressId=ShippingAddressId>
   <cfinvoke component="#application.model.users#" method="getaddress" argumentcollection="#arguments#" returnvariable="arguments.getBillingAddress"/>
   <cfinvoke component="#application.view.orders#" method="ViewReceipt" argumentcollection="#arguments#"/>
</cffunction>

In the first function it gets an address then populates a form for editing that address. Can you picture it? Now the second function calls the getAddress twice. The first time it calls it it sets the addressId=billingAddressId, the second time it sets it to shippingAddressId. Both getShippingAddress and getBillingAddress are then passed into the viewRecipt User Interface.

Think of it like this... The model and view Methods are puzzle pieces. The Controller Methods are completed puzzles.

Steve,

I need to go read about MVC some more. I can understand your examples, and they make sense. But I can also see how it's possible to use an MV framework without any problems. But I'll study up and try to understand it. :)

Steve, at a quick glance it looks like there might be something usable (and more importantly understandable) there.

I suppose this is how some of the other frameworks started out, but then somebody adds a bit of "cool" functionality here, somebody else wants to do something slightly different there, and before you know it you are several versions down the line with a product that can do almost anything but has 500 pages of docs needed to describe how to apply it.

It would be nice if there was an alternative where the primary requirements during development was usability and simplicity. It would also be nice if you could use a basic system then add other functionality in some sort of modular way if needed, so the learning curve was as shallow as possible.

Yacoubean- I'm not sure its wise to pinpoint a single important idea and focus solely on that. But saying that I think you can get away with focusing on a small handful of things. Of course everyones preference is probably different. I'll have to think about mine. MVC is definitely at the top of the list for me, well after indenting code and small file sizes.

Somewhere in your code, whether it is at the top of each page, or in its own seperate file, you must have logic that determines which Model and View ro run/display. That logic is your controller.

Without the controller (and again, it does not necessarily need to be a seperate file), you application wouldn't do anything. Even with spaghetti code, there is logic in each page, though admittedly, it scattered throughout the page, that ceould be considered, at the very least, controller-like.

Steve,

I am curious why you choose to use <cfmodule> for you method calls I used to do it this way, but switched to using <cfset object.method(argumenst) />. It just seems cleaner to me (and, most of the time, would save me some keystrokes).

Mike,

I think you're right. That's one of the big benefits of using frameworks. My only problem with that argument is that there are a lot of frameworks out there today (a new one announced just this week!). It's only a small percentage of the CF population that uses one particular framework.

Now, it's still beneficial though, because you're using a framework that's documented. But you could also have your own documented methodology, and have the same effect. So that argument's out the window. So the only real benefit (of this type, I know there are other benefits) is that there's a small chance that the subsequent developer will be familiar with the framework you used.

I /really/ wish all of the MVC experts out there (Joe, Sean, Hal, Matt Woodward, etc.) would throw their respective frameworks in the trash and pool their resources to make one killer, /standard/ MVC framework. But it'll never happen.

P.C.,

I agree, that would be very nice. I know Simon Horwith has his methodology somewhat published, calle SAM (I can't remember what it stands for). It's not a framework, just a set of OO oriented practices. If you look at the CF Petmarket site, you can see an example of it, but I'm not sure if he's ever actually formally published it.

I just get tired of the flaming if you don't happen to follow frameworks or OO.

It gets pretty offensive sometimes.

A+