Many of us have tried (or at least downloaded and installed) FlexBuilder, the trial version. For those of us who use Eclipse for other things besides Flex and never bothered to actually purchase FlexBuilder, we may find ourselves with a now expired plugin that tends to pop up now and then asking us to enter our serial number. No big deal really, only a minor annoyance. Except for today when I tried to open a CSS file.

I'm not even in the FlexBuilder perspective, but apparently the CSS extension had somehow been associated with FlexBuilder, so now instead of seeing my file open up in all its glory, I am prompted to purchase the product. I tell FlexBuilder "No thanks", but am unable to open my CSS file. So then, the point of this whole post: How to remove the FlexBuilder plugin from Eclipse.

Fortunately it's a very simple process.

1. Close Eclipse
2. Go to the "plugins" directory of your Eclipse installation
3. Sort the Plugins directory entries by name so that all of the FlexBuilder items are together. Highlight them all and send them to Windows Purgatory.
4. Now go to the "features" directory of your Eclipse installation
5. highlight and delete all of the Flexbuilder entries there
6. Restart Eclipse

Aptana is an Eclipse plugin that came to me highly recommended by a peer (Doug Sims) and has proven itself to be a real assett to me as well. What does it do? Only provide code assist with both Javascript and CSS files! Another VERY COOL thing it does within the code assist is provide visual indicators of which CSS and Javascript attributes are IE and/or Firefox compatible, something that is a constant plague to those trying to maintain cross-browser compatibility.

and now for something completely different...visit

Visit Aptana.com and click the "Download Aptana Plugin" link on the right hand side of the page for instructions on how to install.

One caveat of this plugin is that it's code assist feature is only available when working with .JS or .CSS files...inline css or javascript, well, you're on your own.

Look at the following code and guess what the output would be:

Oh, here's the cfc...

Choices:

• A:[empty string]
• B:
  • list item 1
  • list item 2
  • list item 3
• C: depends

The correct answer is C, and what it depends on is whether or not somewhere else within your application a CFSETTING tag is lurking that has ENABLECFOUTPUTONLY set to 'Yes'. If this attribute is in effect, then your result will be A; if it's not, your result will be B.

The reason I felt the need to post on this is the fact that I spent a few hours yesterday developing a mild headache trying to figure out why my perfectly simple cfc was producing an empty string at one point within my app, but the correct string elsewhere. Through experimentation and noting that when I removed the CFSAVECONTENT tags everything worked as designed, I eventually concluded that I MUST have discovered a bug in the framework I was using, and so notified the keepers of the framework of all the details of my investigation and conclusion, along with code samples. They immediately (and nicely) informed me that more likely it was the fact that I had ENABLECFOUTPUTONLY enabled, and that I hadn't included CFOUTPUT tags within my CFC method. With egg still dripping from my face, I added the CFOUTPUT tags to my method and wouldn't ya know it...it worked.

I still haven't taken the time to find out where within this app the CFSETTING tag is being called, but two lessons gleaned here for me:

1. Next time I feel excited at the prospect of having discovered a "bug", I'll think again (nobody wants the reputation of being The Boy Who Cried 'Bug!');
2. Start troubleshooting from 10,000 feet instead of with a magnifying glass.