I understand your position, but disagree. I flatly reject the notion that we should wait for Macromedia to implement a CFML improvement before we can then implement it in BlueDragon. Basically you're saying BlueDragon can't be better than CFMX--a position I simply can't accept.
If we accept your view, then BlueDragon customers who have been using the J2EE edition since 2002 (for example), would still be waiting for Macromedia to deliver critical features (such as standard WAR/EAR deployment on WebSphere and WebLogic) in Blackstone some time in 2005. Why should people who have been taking advantage of BlueDragon's CFIMAGE or CFIMAP tags for almost two years now have to wait for Macromedia to deliver them (maybe) in Blackstone in 2005? For these customers, the advantages of using BlueDragon easily outweigh any incompatibilities they might have to deal with. (Some never intend to go back to CFMX, so for them upgrading to BlueDragon is no different than upgrading from CF5 to CFMX, for example. That is, there's no need to remember the differences after upgrading). I understand there are people who may never try BlueDragon, preferring to stick with CFMX. That's fine. But, we have customers who are telling us they want the innovations and enhancements and improvements that BlueDragon is making to CFML--that that's exactly the reason they're using BlueDragon. As any good business, we tend to listen to the people who are giving us money. :-) I hope you do try BlueDragon some day. You may find something in there you like. Vince > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Adam Cameron > Sent: Tuesday, June 29, 2004 10:50 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] CFEXIT or CFABORT within CFFUNCTION > > My opinion was a considered one. If BD is emulating CF - it > is - it should do precisely that. > > I'm not necessarily thinking of the <cfabort> / <cfexit> > issue (although I *do* think it would be best to behave > exactly like CF does), I'm thinking in general. "Fixing" > something CF does wrong / badly is just the thin end of the wedge. > > I don't want to have to remember "CF behaves [in a given > situtation] like this, but I have to remember BD does it this > way instead". I'd rather have some issue being uniformly > broken/bad/illogical: cross-wards compatibility, if you will. > > The way *I'd* approach this sort of thing is that if there > was some issue that could be done better in CF, petition MM > to improve it, then reflect the improvement in BD. > > I could live with the notion of BD being a subset of CF's > functionality: > "don't forget you can't use <cfsomethingorother> in BD > because it doesn't support it", but the further it strays > from how CF performs the same actions, the less and less > likely I ever am to use it. > > > > Adam Cameron > Senior Application Developer > Straker Interactive > > Ph: +64 9 3605034 > Fx: +64 9 3605870 > Email: [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]
