this as well.
I've had many arguments about this view, but I find it helps tremendously to
view CFCs as "persistable CF templates". The more accepted view is to view
them as objects, and this can be useful, but only if you already know
objects or are attempting to replicate an object-based pattern or
architecture.
Looking at CFCs as CF templates is, I think, probably closer to the truth of
how they were designed. For me it also clears up some of the conceptual
holes when you try to determine why the designers did certain things.
For example:
1) In any CF template the "variables" scope is only viewable by that
template - that's why it makes sense to me that the variables scope equates
to the "private" scope for CFCs.
2) As Raymond said, the way you call a CFC method is exactly equivalent to
way you would call any function in any CFC template. They really are the
same - the terminology is different, but don't let that confuse you - if you
know how to use functions in any CF page then you know how to use methods in
CFCs.
3) In CFCs, just like in any CF template, processing occurs from top to
bottom. Any code outside of functions is run immediately. When I think
about it like this the "pseudo-constructor" (and lack of a real constructor)
makes much more sense: it's just like any template - what's there runs like
it would in any template.
4) Many common CFC questions can be answered easily when you start thinking
like this as well. CFCs use and access most scopes (CGI, Application,
Server, Session, Cookie, etc) the same way as any template. Although there
are larger considerations to using them CFCs use shared scopes, custom tags
and CFINCLUDEs the same way as any templates. For example in a normal CF
template you can CFINCLUDE a page of functions - those functions are then
local to the template. In a CFC you can CFINCLUDE a page of functions -
those functions are then methods of the CFC.
The big difference between normal CF templates and CFCs is that CFCs are
persistable - in other words they can be run, but then stored in a shared
scope and reused. But even this can make more sense if you think about them
as templates: basically a normal template runs, then stops and it's assets
are destroyed. CFCs are run, then stowed instead of being destroyed - their
assets are still available indefinitely.
You can then access them via their method calls (functions) but you can
think of this as running a function on another CF page.
The metaphor breaks down some when you get into thinking about CFCs as
objects, but it still helps. There've been may arguments about how CFCs
aren't "OO enough" - and considered as objects they really aren't. However
considered as persistable CF templates with some object features it makes
(at least to me) much more sense.
CFCs just aren't objects - they are CF templates with some special
capabilities (and limitations) and they act much more like CF templates for
most purposes than like objects.
I'm not sure if this helps or confuses you more, but I find thinking this
way helps me immensely when conceptualizing how CFCs work.
Jim Davis
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
