I believe we need documentation to be as complete as possible, but I do understand that the documentation needs to be accessible as well. Therefore, I think the answer is that in addition to the current documentation, having a formal language specification would allow for folks who are more advanced to be sure of what the expected behavior should be. I'll add that I think such a specification would allow other CFML vendors to ensure that there is a single standard.
-Matt
On Jan 31, 2004, at 10:27 PM, Sean A Corfield wrote:
On Jan 31, 2004, at 8:50 AM, Matt Liotta wrote:Prior to CFMX, CFML had no problems with includes because they happened as runtime.
Includes still happen at runtime.
I'd go on to say that if CFCs were implemented using the architecture of CF 5, we wouldn't even be having this discussion
I don't know. Given that CFMX maintains compatibility with CF5 as much as possible, I suspect it's implementation of cfinclude is very similar to that of CF5.
I believe that BlueDragon shows that be true since it has a similar architecture to CF 5.
An interesting comparison - CF5 was a C++ application that translated CFML to intermediate code and then interpreted it; CFMX is a Java application that translates CFML to Java bytecode and the underlying JVM executes both. BlueDragon is a Java application but I don't know whether it uses Java bytecode or a custom intermediate code - when I challenged that BlueDragon was an interpreted system, Vince led me to believe that it was closer to the compilation system of CFMX...
Take a random binary file and split it into two parts. Next create a CFM that includes the two separate parts in the correct order. Whitespace issues aside, the complete binary file will be served correctly.
Interesting. What about this example:
inner.cfm: blah #blah# blah
outer.cfm: <cfoutput> <cfinclude template="inner.cfm" /> </cfoutput>
If cfinclude is really cut'n'paste, it'll give an error that the variable blah is undefined, right? No, it produces:
blah #blah# blah
And BlueDragon JX 3.0 and BlueDragon JX 6.1 Beta 2 both agree.
There's clearly more than cut'n'paste behavior going on and I think this thread proves that it's actually hard to document (and therefore hard to understand) exactly how cfinclude really does behave (because it involves dynamic relationships between scopes, amongst other things).
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]
----------------------------------------------------------
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]
