I didn't state that at all. I just don't feel that CFC went through design iterations
As someone who had access to the specifications, I can assure you that they did indeed go through several design iterations. The CFC spec changed several times in the early days before even the first implementation - and it continued to evolve through the early product life cycle.
I feel they went through implementation iterations and that makes all the difference.
Yes, if your only view of the the life cycle was through the alpha / beta builds, you could have gotten that (false) impression.
In fact, the above mentions to specific cases, which is inline with a boolean attribute since a boolean represents one of two states. However, that is not the case with CFMX as the output attribute is optional and doesn't default to a value.
I'm following up internally to see if this is considered a bug or a feature (yes, it's documented so you could argue it is a feature but I think it's really a bug and that the default for output= - when you omit it - should be identical to one of the two behaviors you get if you do specify it).
How many people were aware of the above?
I'll admit that I was not. But then I try to make sure I specify output="false" on all my cffunctions (per the examples in the Mach II Development Guide) although I now see that the Coding Guidelines do not require this. Note to self: update Good Practice section of the Coding Guidelines to require output= on cffunction tags!
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word '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]
