I believe that's the way it's always worked: each template is parsed for valid tag before includes take place.
There are some tags I wish this weren't the case for (CFTRANSACTION and CFLOCK to name two) but that's the way it's always worked. Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Stephen Milligan > Sent: Friday, January 30, 2004 2:16 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] More CFMX Excellence with Component Inheritance > > I don't have a pre CFMX server to check any of this on, but what happened > on > CF5 and earlier when you tried the code below? > > In cfmx it barfs because case statements can't be in an include file, and > neither can catch blocks. My fuzzy memory tells me that this was the case > in > CF5 and earlier too, but like I said I don't have an installation to test > it > on. > > If that is the case then I believe the behaviour in CFCs is entirely > consistent with what happened pre CFMX. > > If not then it seems quite clear that CFCs do behave in a way that is > inconsistent with how the language used to work. > > The specific example I remember that makes me think that CF has always > worked this way was putting an opening <cftry> tag in Application.cfm, and > putting the <cfcatch> and closing </cftry> in OnRequestEnd.cfm. I'm > absolutely certain that wouldn't work, but I'm not so sure about the > example > below. > > index.cfm > <cftry> > > <cfswitch expression="#url.action#"> > > <cfinclude template="cases.cfm"> > > </cfswitch> > > <cfinclude template="catch.cfm"> > </cftry> > > cases.cfm > <cfcase value="splash"> > Hey, I'm a splash page! > </cfcase> > > catch.cfm > <cfcatch type="any"> > > <cfoutput>#cfcatch.message#> > > </cfcatch> > > Spike > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of David Ross > Sent: Friday, January 30, 2004 10:53 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] More CFMX Excellence with Component Inheritance > > I think that cfinclude is not cut + paste, and it IS the expected behavior > that you cannot have CFC-specific tags within an included template. > cfargument and cfreturn are integral parts of the cffunction tag, and it's > obvious that they need to be present in order to create the appropriate > method signatures. I have been using CF since pre 4.0, and I'm not > suprised > at all by this behavior, nor do I think it is anything close to a bug. > CFML > has expanded, and this is a growing pain. > The fact that CFCs have a different extension should clue us in to the > fact > that they do not behave the same as a .cfm. I do agree that the docs are > confusing, however... they should be annotated. > > -dave > ---------------------------------------------------------- > 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]
