As would I. I'm perfectly comfortable considering CFCs as special (I like to say "persistable") CFML templates, but this just doesn't jibe.
I'm not sure CFINCLUDEs were ever just like cutting and pasting - you could never CFINCLUDE partial tags (begin a CFIF in one include and end it in another for example). Still, at the very least, there's just a ton of undocumented behavior that really, really should be documented. Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Roland Collins > Sent: Thursday, January 29, 2004 11:52 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] More CFMX Excellence with Component Inheritance > > I would have to agree that while I do see the utility of having CFINCLUDE > work this way in a CFC, it is completely counterintuitive to the way the > rest of CF works! > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Matt Liotta > Sent: Thursday, January 29, 2004 11:36 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] More CFMX Excellence with Component Inheritance > > > It is implemented this way so you can <cfinclude> a function library > > into a <cfcomponent> tag and access the UDFs in it - without polluting > > the methods in your CFC. If I recall correctly, you can also > > <cfinclude> a function library into a <cffunction> tag - which makes > > the UDFs available just inside that method. > > > Interesting... while that seemly makes sense it doesn't really fit with > the semantics of CFML. Prior to CFCs, you could use a cfinclude > anywhere you felt like and the results would be virtually the same as > cutting and pasting the code. The example mentioned in this thread > isn't the only place that breaks those semantics in CFCs. For example, > it isn't possible to use an cfinclude for the entire function body i.e. > you can't cfinclude cfarguments and cfreturn. What is the reason there? > I suspect the culprit in both cases is actually the compiler approach. > It kind of sucks CFML developers now have to concern them selves with > compiler related behavior now when the language was always interpreted > at runtime; cfimport being a prime example. > > -Matt > > ---------------------------------------------------------- > 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] > > > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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]
