If you have a front controller which in order:
1) Fires application.cfc (by way of being a CF page) which defineds app data/settings)
2) Defines a request.context object (session, security login, other global per request stuff)
3) Cfincludes the application page (cfm controller file)
and
4) Each controller gets it's page specific stuff (form data. etc.) by instantiating an object specific to that page, an object which extends a base class (object).

Then, either the page object or the base class (object) can redefine any application settings it needs to, on a per request basis. The application only defines default mappings, data sources, etc., but the page object never reads the application scope directly. Rather, a page object (or controller cfm if controllers aren't object based) would always read app settings from the context object, which gets created at every request by the front controller. The context object overrides settings created in application.cfc as the situation (the context) requires.

Or this kind of arrangement not the way to go?

You took the words right out of my mouth man. I agree with every single point you've made as its totally in line with the golden rule to always favor composition over inheritance. Excellent post man!

When you have a chance, we're working on a project called cfcommons, created by Brian Carr. There will be a Part 2 follow up from Part 1 in which we will implement SimpleMVC to build it into a proper web application where we use composition in Application.cfc instead of inheritance.

We'd love your thoughts, thanks man!

And Ray, yes, it is possible that "evil" is too strong a word. However, I literally don't have a single multi-template application (personal or at work) where FW/1's requirement of having my Application.cfc extend the framework isn't a dealbreaker. This is undoubtedly due in part to personal style, but the fact remains: the front controller is NOT the application. If we could define the application-y stuff outside Application.cfc, then Application.cfc being hijacked by a front controller is no big deal (and would be desirable). But as it stands today, you don't have that choice.

Railo is a good example of providing the flexibility and choice that I personally like so much. For instance I have four ways to define a datasource:
- this.datasource in App.cfc (http://www.railo.ch/blog/index.cfm/2010/2/19/Random-Friday-Railo-tip-thisdatasource) – datasource is Application-specific
- the web administrator GUI – datasource is web-context specific
- the server administrator GUI – datasource is server-wide
- the cfadmin tag – datasource is either web-context specific or server-wide, depending on tag attributes

That said, I think I see your point of frameworks being successful because they do NOT provide flexibility and are built from the perspective of running an app instead of being run by it. I do not particularly like it from a design standpoint. But I guess it makes working together more easy if everyone is forced to do things the same way. And honestly that might be more important than losing some flexibility. And maybe most people find it comfortable to be forced to do things in some standard way. It's just one more thing you don't have to think about, which is a legitimate line of thought of course. I guess I am not like most people ;-)

As for your comment that "cfWheels, ColdBox, Fusebox, FW/1, Mach-II, Model-Glue all dictate how your application runs." True. But some frameworks are more restrictive than others. For example, ColdBox forces my App.cfc to extend their coldbox.system.coldbox cfc. And the framework is loaded in the onApplicationStart event handler. ModelGlue does not force my App.cfc to extend anything, and is loaded by a cfinclude in index.cfm Personally I think the latter is more elegant and allows for greater flexibility, like having .cfm templates in the same app that do NOT use the framework.

Like Ray, I can't imagine trying to use multiple MVC frameworks in a single app so that's a straw man argument.

As for "Framework authors should provide their users with as much flexibility as possible, regarding the way their framework is invoked." – absolutely not true. The framework runs the application by definition. Ruby on Rails is successful because it is opinionated software. cfWheels, ColdBox, Fusebox, FW/1, Mach-II, Model-Glue all dictate how your application runs. They all "force" you to do certain things in particular ways.

You mentioned the "Hollywood Principle" earlier but you got it the wrong way round: the frameworks all follow that principle in that you do not "call" the framework, it calls you. You write CFCs and .cfm pages and the *framework* calls methods on those CFCs and includes those pages.

Now, it's perfectly fair comment if you don't like that approach but I don't think there are any (application) frameworks in the CFML world where your code acts as the controller and invokes the framework…

1) I concur.

2) I guess I just don't see the concern in this – I'd never use FW/1 and Model-Glue in the same app.

As for being positive and not complaining, again, I'll point out Barney's words here – "evil", and "The first problem is due to Adobe's seemingly mindless choice". Those are strong statements and not very constructive I think.

Two points that are important as I see it:
1) It would (sometimes) be practical if per-request settings could be defined anywhere, instead of being restricted to the App.cfc pseudoconstructor

2) Framework authors should provide their users with as much flexibility as possible, regarding the way their framework is invoked. If two frameworks force me to extend their base App.cfc, then it is impossible for me to use both frameworks together. It is all a matter of perspective I guess: is the framework running my application? Or is my application using the framework? I personally personally prefer the latter.

@Sean
"Personally, I like the way Application.cfc works. I don't have any problems with its per-request nature. Application.cfm was per-request too, so I don't really get what you're complaining about anyway… "

It is not the per-request nature of Application.cfc I have a problem with, but the restriction that per-request settings be defined there and nowhere else.

Also, we are trying to exchange technical opinions here, so that we all may learn from each other. If we don't agree with each other, that's for the best. If we all agreed nobody could learn from this discussion. I must say that I find your labeling this as "complaining" a bit demeaning. Please keep it positive!