I realize it’s been just over a month since the last post in this series and for that I offer my apologies. Several things, both work-related and personal have kept me very busy over the last month–hence the couple of short posts in the interim. However, I didn’t want to let this series die before it was finished so I’m going to attempt to wrap up the last two parts in the next few days.
This entry in the series is going to focus on my editor-of-choice–features, a gotcha or two, and why I chose to standardize on it.
As I said in the initial post in this series, I made the switch to Eclipse/CFEclipse just about 2 years ago as my main, day-to-day editor. Like a lot of people, I started out with ColdFusion Studio (version 4.5 in my case) and used it almost exclusively until ColdFusion MX came out thanks to the updated extensions that provided support for the new features in ColdFusion 5. From there I actually spent 2 or 3 years doing all my coding in the code view of Dreamweaver (don’t laugh, if you didn’t use all the WYSIWYG features of Dreamweaver, it wasn’t that bad).
About 6 months before I made the switch to CFEclipse permanent, I downloaded it to give it a try. Not understanding all the workspaces and projects concepts that it introduced as a method to managing multiple code bases, my trial didn’t last long and I soon went back to Dreamweaver. Not long after that I began getting interested in doing Flex development with Flex 2. I downloaded the standalone Flex 2 IDE (which is Eclipse based). Not long after that I sat in on a presentation by Charlie Arehart via the CFMeetup group talking about the virtues of step debugging and introducing FusionDebug from Intergral (which was also Eclipse-based).
At that point it began to be a real pain to switch back and forth between Dreamweaver and Eclipse (FusionDebug) so I decided to give CFEclipse another try. I’m not 100% for certain, but I think Mark Drew released at least one new version of CFEclipse in the time since my first trial. Once I figured out how to arrange my workspace and how to correctly set up projects (both stand-alone and from Subversion) I really began to enjoy the fact that all these tools were available in a single application simply by changing “perspectives”.
By the way, that’s the gotcha that I mentioned. If you are considering trying out Eclipse/CFEclipse, do your homework on how your projects should be structured and configured. I’ve probably been guilty of trying 3 or 4 different setups before finding the one that suits how I work. I’ve tried different workspaces for each client (but then you have to replicate all your preferences from one to another and that gets old). I’ve finally settled on putting all the projects in one particular workspace and setting up different “working sets” for each client and including only that client’s projects in the working set. Working sets are quick ways to filter then entire project list down by client.
The other primary reason that I use it is because Mark and company are actively developing on it and adding new features. CF Studio / HomeSite+ isn’t being updated any more and Dreamweaver is a pretty costly piece of software for just editing code. CFEclipse offers all the tag/function insight that we’ve all come to depend on, help files for the tags and functions, snippet support including a centralized snippet repository for teams called SnipEx and more. The fact that it and the majority of the plugins I use (and hundreds more that I haven’t had a need for yet) are free doesn’t hurt either.
If you haven’t given CFEclipse a test drive lately (or at all), you really owe it to yourself to use it for a couple of weeks and form your own opinions. I realize that no editor is going to be the “mac daddy” (pun not intended Apple so don’t sue me) to everyone, but for my time and effort, Eclipse-based editors are just what I need to jam out code on a regular basis.