Frameworks shouldn't change anything... if properly implemented, your
CFCs should have absolutely no dependencies on any framework, external
scope, etc. This isn't a debate, and definently isn't "cult blindness".
Encapsulation is a tried and true software engineering principle. Most
of the projects I work on that use CFCs use a framework, and I have no
problem keeping them completely "unaware" of their surroundings.
Frameworks change absolutely nothing about the virtues of
encapsulation... in my mind one thing a framework should do is make it
easier to accomplish.

-Dave

>>> [EMAIL PROTECTED] 09/29/04 6:28 PM >>>
Encapsulation debate rages like a cult blindness. There is good reason
for
encapsulation... but if you follow that using request variables is
always
bad (or functions) then you could never use a CGI variable inside a CFC
either... that would have to be passed it. (HEH!) Note... this isn't
aimed
at you Dave... it's just a bad bill of goods to believe that this virtue
is
universal. It is best "general" practice.

1. If your CFC is designed to work in a Framework/Methodology ... like
mine
are, then this is less of an issue. It's like the CGI issue mentioned
above.

2. I declare an universal UDF library that has the udf to do standard
UDF
library included. In "my case" the CFCs are designed to run inside my
Framework/Methodology... therefore calling the library and running the
UDFs
in request scope is a GOOD design pattern. If you negate the framework,
then
the other argument has more merit. Frameworks change the tenure of the
discussion.

:) IMHO... heard the debates and my understanding is that inside a
framework
the rules are similar... but the implications are not.

John Farrar
SOSensible
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' 
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to