Thanks. I like the methods, just wasn't sure how I would deal with
redirection. It sounds like the consensus is that it is very appropriate to
do a redirect from the Application.cfc
Thanks,
Andy
-----Original Message-----
From: Jared Rypka-Hauer
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:198688
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=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
