CFEclipse: Pros, Cons, and Misconceptions

I'm sitting in JFK airport in New York and my flight back to Raleigh was cancelled due to the storms on the east coast. Fun stuff. So I thought it might be a good time to pull a "Peter Bell" and churn out a couple of blog entries on my new MacBook.

Last week an interesting and heated discussion was going on at the CF-Talk list regarding ColdFusion code editors. I chimed in with a response that will probably surprise no one who reads this blog: I trumpeted CFEclipse. What surprised me was the range of responses the topic of CFEclipse had among the broad CF-Talk crowd. Some people agreed with my praise for it. Some people were openly uncertain. Not too surprising there.

No, the surprise came from the number of people who either had negative feelings about CFEclipse or who openly bashed it. And once I got into deeper discussions with these folks, one theme emerged: most detractors of CFEclipse have deep misconceptions about how it works and what it can do.

Some lamented that lack of any site-wide search capabilities. Others derided the fact that you can only intent code one line at a time. Uncompelling snippets, no easy way to test some code quickly without creating projects, lackluster tag editing/insight, or undesired keyboard shortcuts.

Anyone who uses CFEclipse already will instantly recognize that all of these complaints are actually non-issues. There is full site wide search. You can indent blocks of code with no problem. The snippets are extremely powerful. The scribble pad makes quick tests a snap. It has plenty of tag editors and tag insight for all tags and functions (even CF8 already). And the keyboard shortcuts can be extensively customized.

So the majority of the issues people seem to have with Eclipse are not actually issues at all. In this regard, it appears that fans of CFEclipse need to blog or present more on this topic to raise awareness, because this is a shame.

However, there were a few concerns that are more substantial:

One is the memory footprint of Eclipse itself. I run MyEclipse, FlexBuilder, and Aptana alongside CFEclipse and it will routinely use about 150 Mb of physical RAM. My large number of plugins is probably on the very high end, but even so, many people seem to think 100+ Mb of memory usage is too much.

I'm not sure if that is a vocal minority or not, because I simply didn't think anyone but a tiny percentage of ColdFusion developers are working on systems with less than 1 or 2 gigs of RAM. RAM is so cheap now (I found a 2 Gb stick for $68) and I have a hard time grasping why anyone would still limit themselves to 512 Mb. However, I suppose it can't be denied that Eclipse does eat up a good bit of RAM. If someone truly has no way to get more RAM this is indeed a showstopper.

Another common complaint was the fact that you can't just click on a file in your file explorer and open it in Eclipse. This is also a valid observation, but I was somewhat surprised by how many people were bothered by this. For me, when I'm working, I'm working. Eclipse is open, and my workspace and projects are all right there. If I need to open a file, I open it from here. It's rare than I just unexpectedly need to open a single file. Am I alone on this or am I unusual and this limitation of Eclipse is really a problem? I'm also not entirely sure why this limitation exists. Is it because Eclipse doesn't know which project or workspace you need to work with if you open a file outside of it?

This relates to another seemingly major problem: the fact that Eclipse pushes its approach of workspaces and projects upon us. I realize this is primarily a carryover from its Java roots, where most projects require external packages, build paths, and other settings. However, with the ability to integrate with Subversion and the integration with ANT that can be leveraged at the project level (like automatically running unit tests when you save a file), I don't really mind this setup. To me it was just a change in approach that took a little time to get used to, but only a little.

Finally, a lot of the issues seemed to be related to the learning curve associated with Eclipse. There's no doubt that it is more difficult to set up, configure, and update than a commercial package like Dreamweaver. Lots of panels, update sites, plugins, configuration options, and setup processes. I know Mark has an install of Eclipse with CFEclipse pre-configured, and that certainly helps, but it seems like people need more help. The CFEclipse TV videos that are available also help a lot, but many thread participants weren't even aware they existed. Again, do you think fans of the IDE should do more to raise awareness, or do the new users bear some responsibility for taking more time and effort in learning about the help that is already available? And further, is this a case of "you can lead a horse to water but you can't make him drink?"

Time permitting, I'll try to record a Connect presentation on setting up and/or using CFEclipse. My goal will be to try to show anyone who misunderstands what the IDE can do what its real capabilities are and how it's actually quite easy to use once you've spent some time playing with it. It really seems to come down to the fact that people are comfortable doing things they way they always have, and are averse to change and the uncertainty it can bring.

Comments Comments (18) | | Digg It! Digg It! | Linking Blogs Linking Blogs | 11009 Views

Stub Generator for CFCs, Unit Tests, and More

I've created a new and much improved CFC Stub Generator and want to see what people think of this idea. It will generate CFCs, unit tests (for CFUnit or CFCUnit), mock objects, test runners, ColdSpring XML, and ANT unit test build XML files from a simple text file.

You can download the code in the sidebar. I've also submitted an RIAForge project for it. To show how it works, I created a Connect presentation about using the CFC Stub Generator. Have a look and let me know what you think. Thanks.

(Quick aside since I don't think I explicitly mentioned it, you can get the CFCUnit facade for the unit testing tab in CFEclipse at Sean Corfield's blog.)

Comments Comments (10) | | Digg It! Digg It! | Linking Blogs Linking Blogs | 6654 Views

Subclipse 1.1.9

Another quick post relating to Subversion and the Subclipse plugin for Eclipse. Over the weekend I realized there is a version of Subclipse specifically for Eclipse 3.2 (Callisto). You can get it by creating a remote update site and pointing to "". Here is the change log.

I found this because I was getting tired of manually right clicking and choosing "update" to update my local files from the repository. This new version allows you to define keyboard shortcuts for common Subclipse tasks! Much easier, now I can just choose a project and hit Alt-U to get latest from the repository. I thought I'd pass this on in case anyone else didn't know about the newer version.

Comments Comments (2) | | Digg It! Digg It! | Linking Blogs Linking Blogs | 6770 Views

MyEclipse, CFEclipse, and Eclipse Configuration Tips

I saw some folks discussing and asking questions about MyEclipse, CFEclipse, and Eclipse in general on the CF-Talk list. I've been using all of these with good results so I thought I'd share some of my experiences using these tools.

First, the background. Eclipse is primarily a Java IDE, but is extensible through plugins, and there are a ton of them. CFEclipse is a plugin that helps you create ColdFusion applications by offering tooltips, validation, and much more. MyEclipse is a commercial bundle of plugins. Even FlexBuilder is a plugin. The nice thing about Eclipse is that you can pretty much snap any or all of these plugins into your installation.

Normally, to install a plugin into Eclipse you use Eclipse's built-in upgrade functionality in the Update Manager. This is under help-software updates-find and install. You can usually point it at the appropriate URL (look at the plugin documentation or site information) and let Eclipse pull down and install the plugin. It will restart and you'll be set.

Other times you have to manually download a zip file containing the plugin and extract it to your plugins directory. Be careful that you are putting the plugin in the correct place.

Yet other plugins, like MyEclipse, actually have their own installer. Since MyEclipse is a commercial plugin package, you have to run the installer and enter a valid serial number to be able to use it. You just point it at your Eclipse installation and it does the rest.

As an aside, sometimes you can install a plugin and it just won't show up. In cases like this, I've had luck with starting Eclipse in "clean mode". Set up a shortcut to Eclipse like "eclipse.exe -clean", which sort of kicks it in the butt and makes it reload everything.

Now before you run off and start downloading and installing all these plugins, I urge you to hold back for a moment and go read up on managing multiple Eclipse installations (thanks to Andy Jarrett for blogging that back in '05).

The idea here is to separate your core Eclipse installations (3.1 vs. 3.2 for example), your Eclipse workspaces, and your Eclipse extensions (plugins) into separate folders. This way it is much, much easier when Eclipse 3.3 or whatever comes out. Instead of having to reinstall all the plugins again, you can just point the new version at your extensions folder and bam, they're all sucked in. The same goes for your CFEclipse snippets (put them in the extensions folder) so multiple installations of Eclipse can all point to the same set of snippets.

Doing this is not very easy and it doesn't gain you a whole lot right now. But going forward this results in a much more maintainable setup, believe me.

One last bit of advice: back everything up. Eclipse is pretty huge, but since it is a Java application it is completely standalone. That means you can literally just copy all your Eclipse folders to a backup location with no issues. If you ever corrupt the installation or something horrible goes wrong with your system, you can easily restore. Don't underestimate how much time you will save by not having to completely rebuild everything. Trust me on this, I've had to do it both ways and the simple copy and paste beats the pants off reinstalling everything.

Eclipse is a great IDE but it has its prickly points and annoying nuances. It takes a while to get used to using it but the benefits are well worth it. Let me know if any of this is helpful, and if you have any tips or tricks of your own feel free to post about them in the comments.

Comments Comments (2) | | Digg It! Digg It! | Linking Blogs Linking Blogs | 8346 Views

The Coding Holy Grail in CFEclipse?

I've been playing with Eclipse a lot lately to help me learn more about Java. Using Eclipse to write Java code is just a joy, and I wanted to point this out in the hope that maybe CFEclipse can eventually get us to this point with our CFML coding. It might not even be possible (or just extremely difficult) to do this in a language like CFML that is not compiled until runtime, but hey, a guy can dream.

I'm a big fan of a development approach called "Coding by Intention". The basic idea is that when you start coding something like a CFC, you should write the "high-level" methods first, but each line of the high-level method is actually a call to a lower-level method that hasn't even been created yet. So you might do something like:

<cffunction name="processForm" access="public" returntype="void" output="false" hint="I validate the form and insert the data into the database.">
   <cfargument name="data" type="struct" required="true" hint="The raw form data." />
   <cfset var validData = "" />
   <cfset validData = validateData( ) />
   <cfset getDAO().save( validData ) />

Where validateData() and getDAO() aren't even created yet. They'll be private methods. The idea is to write the "sergeant" method and pretend that whatever you need is already there. Once you know what you need it's fairly easy to go back and create each of the individual "private" methods.

My real point here isn't to harp on "Code by Intention" but to exalt how easy Eclipse makes this when writing Java. Imagine you're coding in Java and you write the line:

Person p = new Person("Brian");

You can then put the cursor over "new Person" and press Control-1, and a little pop up offers you the choice to "Create Class Person?". How nice, you think, and click it. Bam, a skeleton Person class is generated. Again hover over "new Person" and hit Control-1, and now it asks "Create Constructor Person(String)?" You click that and a constructor skeleton is created that matches the arguments that you declared.

You can do this for any "Code by Intention" methods you create and it will spit out the private methods with matching method signatures. Further, you can go to the Refactor menu and do all sorts of crazy things like automatically create factory methods and make the constructor private, generate getters and setters, move common methods up the inheritance tree, etc. And whenever you do these things, the IDE automatically updates all references in your project to reflect the change.

Can you imagine doing things like this to write CFML? To me this would be a Coding Holy Grail. Now I know that some (all?) of this would be extremely difficult in a typeless, runtime language like CFML. My hope is that bringing these features up to folks who might not be aware of them will generate interest in trying to do these things in CFEclipse. To be honest I never knew IDE's could do things like this. So, would features like this be useful to other CFers or am I just wigging out because I hadn't seen things like this before? Are things like this even possible goals for CFEclipse?

Comments Comments (3) | | Digg It! Digg It! | Linking Blogs Linking Blogs | 5045 Views

Previous Entries