I just found Charlie Arehart's new blog. In the comments of his second post Charlie and Ray start discussing the joys and pain of having two config files vs one config file.

One person I worked with turned me onto something he called Inversion of Control, which is a design pattern. I have found it is a rather elegant solution to the config file issue. This is how he set it up:

This config file extends all the values from the first, and therefore inherits the all the this.x instance variables. We just overwrite our custom config options for the localhost. Most commonly, it is directory paths that change.

In this application we were loading the config values into the request scope. on the OnRequestStart event we added this code:

The first line gets the domain name. The second line instanstiates the component and copies all the instance variables into the request scope. I thought it was a pretty sweet approach and it has worked out pretty well. If Ray was so inclined to change it, I see no reason why Blog.cfc couldn't use a similar approach.

Also take a look at Simon's article on frameworks, OO, and Design patterns.

Simon is, once again, rocking the boat. I do agree with a lot of his assertions, though. To quote a few:

The most significant benefit that organizations stand to gain from using frameworks is a standardized way to code and an environment that is generally more conducive to allowing multiple developers to work on a project at the same time

I think this is the best reason to choose a framework. Consistency of Code leads towards ease of long-term maintenance.

This is another one:

Most of the books, courses, and, therefore, developers today have completely missed the point when it comes to OOP

At one point I used to know the difference between OOP and procedural programming. That was when I fresh out of college. But, talking to other developers and reading about such concepts over the past two years has completely confused me. A year ago I never would have called my development style object oriented. However, there are many people taking similar approaches and calling them just that.

Many people say that Design Patterns are OO. But, I don't understand why. In fact, I believe that many of the OO patterns can be applied to procedural programming. As far as I can tell, most patterns are just ways to encapsulate code that provide the most flexibility for change over the long term. That is not unique to OO or Procedural stuff.

Whenever programmers, like us, talk about design patterns, we're talking about high level approaches to architecting code, with the intent of improving flexibility and maintanability in the long-term.

Most people I speak to generally think about design patterns as an OO-specific concept. I'm in the process of reading Head First Design patterns, and don't really understand why any of the concepts are covering are OO specific. Many of them can apply to 'procedural' type design also.

Apparently, Yahoo agrees with me. Design patterns are not an OO specific concept. They recently released a set of Design Pattern Libraries. These libraries have nothing to do w/ architecting applications; they are all about the view (or User Interface). Things like navigation tabs, search pagination, 'object' ratings, and writing reviews are not something you'd find in the "model" portion of your app.

Along with the UI Design Patterns, they have released libraries of AJAX related UI components.

I haven't delved into any of this yet, but clients are clamoring for for some of the functionality they see in Yahoo (and Google) products, so perhaps this can give you (and me) a headstart.

I wonder if Amazon.com sues has patents over things like "writing a review" and "rating an object".