The tristate boolean is the output attribute. If it's missing, it treats the body as normal template text (need CFOUTPUT to output), if it's set to true, it treats the body as if it's surrounded by CFOUTPUT, and if it's set to false, it treats the body as if it's surrounded by CFSILENT.
CFCs do have their problems (you mentioned three), and while I realy like them, I'm totally with Matt here. Somone had their head up a certain orifice on this one. cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Sean A Corfield > Sent: Thursday, November 13, 2003 11:52 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Native CF tags and local scope > > > On Wednesday, Nov 12, 2003, at 11:47 US/Pacific, Matt Liotta wrote: > > The very fact that CFCs went through a lot of implementation > > iterations shows just how slapped together they were. > > Are you saying that you don't go through design and implementation > iterations when building software? That would make you very unusual in > the software world... ;) > > > There are plenty of examples where design flaws became features e.g. > > the pseudo-constructor area or worse, the output attribute. > > I agree that the pseudo-constructor idea was less than ideal but most > folks seem to be standardizing on init() as a constructor and only > using the pseudo-constructor for bare bones default value > initialization (like other languages allow initial values to be > specified for instance variables). Hopefully we'll get a fully-fledged > constructor notation in a forthcoming version of CFMX. > > I'm not quite sure what you objection to the output attribute is - > could you elaborate? > > > Why anyone would think it would be a good idea to apply tri-state > > logic against a boolean attribute I don't know. > > ??? > > > I can't imagine how an OO person would be very happy with CFCs > > considering how shallow the OO capabilities of CFCs are. > > Well, just because you can't imagine it doesn't make it less true :) > > I would like to see: > a) interfaces / implements > b) an integrated constructor notation > c) null > > I can live without the second item since I have adopted a style that > works much the same as 'real' constructors: createObject().init() > > The first one is harder to live without in an OO world (but it is > possible to live without it). > > The third item isn't really specific to OO but the absence of null can > make certain patterns harder to implement elegantly. > > So, yeah, even as an OO language diehard (eight years on the C++ > standards committee and doing hardcore C++ development, nearly seven > years of Java development), I find CFMX pretty good for OO development. > > 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] > ---------------------------------------------------------- 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]
