I agree with you Sean - regarding the "best practice" issue. The Application CFC is a pretty new feature (and one that I certainly haven't looked at in terms of "How will I manage this?").
But it's certainly possible and mimics the concept of the <cfinclude> as you have said. But - again - that was something, with Application.cfm, I stopped doing about 4 years ago. I guess only time will really tell on the "best practice" issue. AND... I think there was another question as part of this thread that asked something like "How do I get to the methods/members if I do 'override' the class?". Simple - via the Application scope where all your application variables are stored. Regards, Gary On Sat, 5 Mar 2005 12:58:02 -0800, Sean Corfield <[EMAIL PROTECTED]> wrote: > On Sat, 5 Mar 2005 13:28:19 +0100, Nando <[EMAIL PROTECTED]> wrote: > > Ummm ... that's not what i was thinking. I thought the post referred to > > something like this ... > > > > <cfcomponent extends="Application"> > > > > </cfcomponent> > > > > ... and i was wondering what cool thing one of you guys had come up with to > > do with something like that. :) > > But it wouldn't do anything useful. CFMX 7 only looks for > Application.cfc and only instantiates and executes the Application > object - it won't see anything that extends Application.cfc > > Now, the one case where it *might* be useful is if you do what we do > on macromedia.com where we have /Application.cfm and > /appname/Application.cfm which starts out by <cfinclude>ing the root > Application.cfm file. Given an appropriate mapping, you could have a > root Application.cfc and then appname.Application could extend > root.Application (it couldn't just extend Application since that would > be in the same directory). Then each of your on*Start() methods could > begin by calling super.on*Start() and each of your on*End() could end > by calling super.on*End(). Nice, neat reuse (and this is a case where > inheritance is OK because an Application object is-a Application > object). > > The other thing you could do is have your application start/end > methods defined in a tree of CFCs outside the webroot and then just > have each Application.cfc extend the appropriate CFC from the tree: > > components/ > BaseApplication.cfc > app1/ > App1Application.cfc (extends BaseApplication) > app2 > App2Application.cfc (extends BaseApplication) > webroot/ > Application.cfc (extends BaseApplication) > app1/ > Application.cfc (extends app1.App1Application) > app2/ > Application.cfc (extends app2.App2Application) > > You Application.cfc object would be completely empty - all of the > logic would be in the Base / App1 / App2 versions. > > Not sure whether I think that's good practice or not... > -- > Sean A Corfield -- http://www.corfield.org/ > Team Fusebox -- http://www.fusebox.org/ > Breeze Me! -- http://www.corfield.org/breezeme > Got Gmail? -- I have 49, yes 49, invites to give away! > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
