Andy, If I understand correctly, it's an either/or situation. There was a similar conversation on CFCDev the other day, although it was mostly centered on extending application.cfc, and the concensus was that they should be used as intended, even if there were ways of doing customized versions of them
The point with application.cfc is twofold, from my perspective... one is to facilitate the new "events-style method triggers" (onApplicationStart, onApplicationEnd, onSessionStart, onSessionEnd, onRequest, onRequestStart, and onRequestEnd), and the other is based on the first... facilitate a higher degree of standardized application management. It makes for a cleaner system when the application is managed by a subsystem that's very similar to the rest of the implementation. In this case, rather than storing an independed CFC in the application scope, the application scope itself becomes a CFC... so method calls change when dealing with application-scope CFCs... from application.myCFC.methodCall() to application.methodCall(). It also allows the application-scope CFC to maintain private data in it's variables scope and public data in it's THIS scope... There's also no convenient way to manage the onRequest, onRequestStart and onRequestEnd events... any other way of dealing with them are going to be messy and incomplete at best. And, since there IS no other way to manage the on*End() for session and application, application.cfc represents some functionality that we've simply never been able to accomplish before, in any way. I don't think it's too messy to have an application.redirect("location","addToken") method... since that method is based on getPageContext().forward(), it's just mirroring the underlying Java to accomplish the same thing. I did a site that made heavy use of cfscript to manipulate CFC instances, and I wrote a UDF to provide exactly that call... worked perfectly, too. To answer your question, where you have 2 files with the same stem and different suffixes, the system has always resolved them in alphabetical order... hence application.cfc would fire first. The real question is whether or not they're both automatically utilized when they both exist. Index.cfm will be chosen over index.html where they both exist because cfm is earlier in the alphabet than html... since index.cfm takes over, index.html never gets touched. But I don't know if application.cfc will execute and the normal "auto-include" will fire for application.cfm after that. Laterz, J On Sun, 13 Mar 2005 13:20:38 -0600, Andy Ousterhout <[EMAIL PROTECTED]> wrote: > Jim, > I am just concerned that redirecting out of a CFC might create sloppy code. > I would probably want to continue to use Application.cfm for the redirecting > or use an include at the top of every page. > > Can I use both Application.cfm and Application.cfc? If so, what order do they > get executed in? > > Andy -- Continuum Media Group LLC Burnsville, MN 55337 http://www.web-relevant.com http://cfobjective.neo.servequake.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:198605 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54