Clearly you are in the minority in terms of expectations in this thread
So it appears :)
Do you think it is expected that cfinclude shouldn't be allowed to include the entire function body e.g. the following.
<cffunction name="foo"> <cfinclude template="foo.cfm"> </cffunction>
I would only expect that to work if foo() took no arguments and didn't return a value. "include" works like most folks in this thread seem to expect in C / C++ because those languages have a preprocessor that is a simple text substitution engine. When you compile a C / C++ program, the source code is preprocessed first - all includes and macros are processed - and then the resulting source code is compiled. This sort of naive source code processing is powerful but not considered a very good model by a lot of language advocates (well, advocates for languages other than C / C++!).
In almost all other modern computer languages, there is no preprocessor and files are compiled on a per-file basis which means that each file must be syntactically correct in its own right. Since <cfargument> and <cfreturn> only make sense when they are inside a <cffunction> tag, it seems reasonable to me that you can do this:
<cffunction name="foo">
<cfargument name="bar">
<cfinclude template="foo.cfm">
<cfreturn 42 />
</cffunction>but you can't have an 'include' file that contains this:
<cfargument name="bar">
<cfreturn 42 />because that is not syntactically valid. When you think about how CF has always treated files - that they can be <cfinclude>'d or *called* as custom tags - then there ought to be at least a suspicion that <cfinclude> doesn't behave quite like cut'n'paste (despite what the docs say).
And that brings us to the docs. The obvious way to explain <cfinclude> is to say it's like cut'n'paste because most people understand that - especially folks with little or no programming background. Now, as several folks here have complained (and rightly so), that explanation totally breaks down when <cfinclude> is used in the context of a CFC. That's not because CFCs are inherently broken but simply because of the way that <cfinclude> has always really worked, i.e., it ain't cut'n'paste.
Now, when CFMX6.0 came out, there were certainly some strange (and often glaring) bugs in the ways CFCs interacted with many other parts of the language: 'variables' scope was totally broken, <cfargument>'s were not accessible if you <cfinclude>'d the function body, you couldn't declare 'local' variables or even non-public instance variables. So, yes, CFCs were broken.
CFMX6.1 fixed them. You may argue that it didn't fix them enough - certainly CFCs are not (and probably never will be) clones of Java's classes. There's a lot of reasons for that and I know that not all of you agree with those reasons. But, the basic things that were intended to work (but didn't in CFMX6.0) did get fixed.
CFML developers never needed to understand implementation details before and they shouldn't now.
Well, I might take issue with that (but right now I won't bother).
Further, such a description doesn't begin to explain why the behavior of cfinclud differs depending on the context in which it is used.
Technically, the behavior does not differ based on context - a <cfinclude>'d file is, after all, just another 'page' object that is invoked from the calling 'page' object. Since scope lookup is dynamic, 'variables' and 'arguments' bind to whatever the calling scope has which makes it appear to be context-dependent.
I don't think CF is a perfect language by any means and I've been critical of several of its shortcomings but I've also come from a CFMX-only world so I'm not trying to see CFMX through CF5 glasses (in fact, if anything, I tend to see CF5 through CFMX glasses!). For me, CF has always had components and has always compiled each file (and each function) to a separate (bytecode) class.
Hope that helps clarify both my position and the behavior of <cfinclude>.
Regards, Sean
----------------------------------------------------------
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]
