I think the debate here seems to be a disjunct between a procedural view of the world
(pre-CFCs) and an object-oriented view of the world (CFCs). I actually wonder whether
using cfinclude inside a cfc is a good idea at all. Its not that I don't think the
idea of being able to include functionality from other libraries in a cfc is a bad
thing, but I think this discussion highlights that it semantically confusing to allow
use of cfinclude inside of cfcs.
Wait, wait, don't kill me. I understand that many don't want to know about
implementation details, etc. and want components to work like pre-CF6. The problem
you face if you want components to work like your procedural code is that they cease
to add real value at that point. The big value added is that you are forced NOT to
create code with undocumented assumptions. CFincludes may be a nice way to slice code
up in into manageable bits, but how many times have you seen someone with a bunch of
bugs caused by includes that a)didn't have all their variable declared with CFParams
or b)resulted in variables switching values unexpectedly because of the inability to
scope them privately. I have seen several posts to this very list on problems with
recursive code caused by folks forgetting to scope their vars. In summary:
encapsulation is a good thing, it protects you; includes don't allow you to
encapsulate, so they give you a dangerous level of flexibility.
This leads me to question why this is even brought up in the docs as a 'good idea'.
Developing Cold Fusion MX Applications (6.1) sez on pg 237
-----------------------------------------------
PUTTING METHOD EXECUTABLE CODE IN A SEPARATE FILE
You can put component executable code in a separate file from the main
component definition
page.By placing the method execution code in a separate file,you can separate
property
initialization code,meta information,and the method definition "shell"from the
executable
method definition code.This technique lets you modularize your code and helps
prevent CFML
pages from getting too long and complex.
To separate the component method code,use a cfinclude tag on the component
definition page
to call the page that contains the component method code.
Note:If your method returns data to the page that invokes it,the cfreturn tag
must be on the
component definition page;it cannot be on the included page.
To create component method using the cfinclude tag:
1 Create a tellTime.cfc file with the following code:
<cfcomponent>
<cffunction name="getUTCTime">
<cfinclude template="getUTCTime.cfm">
<cfreturn utcStruct.Hour &":"&utcStruct.Minute>
</cffunction>
</cfcomponent>
------------------------------------------------
I don't understand the benefit here.
I think what people want is the equivalent of Java's import statement (well, ok, it's
what I want). If I have all of my cryptographic methods rolled up inside crypto.cfc
(eg MD5Hash()) so that I can use them from whereever by instantiating a crypto object
I would like to be able to do something like:
<cfcomponent>
<cfcimport package="bar.foo.util.crypto"/>
...
<cfscript>
test= MD5Hash('ChipTemm');
...
I know that we are able to use CFInvoke, but in my experiments this costs the same as
instantiating the object and invoking the method. I want to be able to invoke the
crypto class' static methods without the cost of instantiation. How does this differ
from a UDF library include? Well, for one semantically I won't expect cfcimport to act
like cut'n'paste. I will expect it to act like a CFC.
So I guess my point is that I agree with Sean that includes "...clearly should not
behave like cut'n'paste.." in the context of CFCs. BUT, I also see the point of most
of the other commentators on this thread that CFInclude will be expected by CF
veterans to behave as it always has. I would say the confusion could be addressed by
a CFCImport tag/function in conjunction with changes to the docs to indicate that
CFIncludes are not a best practice when used in CFCs.
Chip Temm
Director, Knowledge Architecture
Center for Applied Biodiversity Science
Conservation International
Ste 600
1919 M St NW
Washington, DC 20036
USA
+1 202 912 1402
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
----------------------------------------------------------
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]
