Cutter's Crossing - CFEclipse

Tools Make Life Easier

Thu, 15 Mar 2007 23:38:00 -0400

I am a huge fan of things that make my life easier, and love tools that do just that. It's kind of like moving from writing my thoughts down on paper to using a computer, I still (try to) write quality content, but it's not nearly as time consuming now. I can write, read over, rewrite a piece over and over agian, without wasting a load of paper, correcting seven million spelling mistakes, or emptying a white-out bottle. Tools are those things that you use to get a job done, and there are almost as many tools as there are jobs. Tools are those wonderful things that separated man from animal. Funny thing about tools, though, not every tool will handle every job. You have to try them out, take 'em for a test spin, work out the kinks, and see what works best for your development style. Once I got past the learning curve, Model Glue: Unity turned into a natural flow of MVC development, ColdSpring has assisted me immensely in managing my object dependencies, and Reactor's scaffolding has slimmed down the gruntwork of creating my CRUD methods. This is part of the job of frameworks, to make our lives easier. CFLib and the ColdFusion Cookbook are repositories of experienced knowledge, condensed into freely usable bits of logic. RIAForge takes it to a whole other level, by providing us with entire applications. All of these are tools for making our lives easier. (How many times was Ray indirectly referenced there?) But, it's important to not become married to any one toolset, which is why I keep my nose in Mach II and Fusebox, have started checking into Transfer, and really like the simple flexibility of tools like DataMgr and AjaxCFC. You never know what the next project might call for. The ColdFusion community has progressed leaps and bounds in the seven years I have been a part of it. As a language, CFML has added constructs to utilize object oriented design patterns, create dynamic reports in a variety of distributable formats, and given us the ability to create server event driven functions, just to name a few of the changes. Open Source projects are all over the place, the server is used in a majority of Fortune 100 companies, the government (of all industries) has adopted this 'expensive' platform like gangbusters, and demand for experienced developers is through the roof. And when Scorpio gets released the 'other guys' won't know what hit 'em. So, open up CFEclipse, use Subclipse to checkout some of the wild goodness from their respective repositiories, and start exploring. Take a deep look into their core files (but, don't change 'em!) for some insight into the style of some of the masters of our industry, and look forward to a very bright future. ColdFusion has helped take the guess work out of some complex tasks, and it's only getting better. And easier!

It's here

Sun, 28 Jan 2007 02:16:00 -0400

But, you already knew that. (Sorry I'm late to the party, I've been busy studying for my exam, etc.) The suspense was killing everyone, it seems, on what all of the mysterious banners were that popped up on several key blogs (including mine? Now how did that happen?) Then came 'the hunt', that cool programmer's puzzler leading to the video. Finally Version 1.3 of CFEclipse is out of beta and available for download.

Over the coming weeks Mark and the crew will be putting out some info on the new features of CFEclipse. Most of the changes aren't very evident to those who've been on the beta, but one of the immediate enhancements I noted was the template introspection when I began to reference variables I had previously defined. Nice time saver. What goodies have the rest of you spotted?

The entire CFEclipse crew has been hard at work over the last year knocking off the bugs that had been reported, doing some fine tuning, plus cranking out a new site (which is still a work in progress). Truly great stuff from Mark Drew and everyone else on the CFEclipse project. So A) donate to their various 'conference' donation setups, and B) buy them lots of drinks at said conferences. Last I checked Mark was heading off for a well deserved trip to the pub. Someone buy that man a JD and Coke.

The New CF IDE

Wed, 02 Aug 2006 01:16:00 -0400

OK, what are Damon Cooper and the Adobe crew up to? There a post on Damon's Blog on What's Your Ultimate ColdFusion IDE? This has gotten some very interesting responses. Overwhelming support for CFEclipse, with suggestions on what to extend in it's feature set (everyone says 'Debugging').

And then Damon makes this cryptic remark:

Guys, thanks for the feedback this far. Much appreciated. We've heard you all loud and clear, and I, at least, realize now more than ever from this small sampling of feedback that our suspicions were correct. I sincerely hope we can both pleasantly shock and awe you with what we have on store. I will say this: the solution we come up with may not be what you're expecting, but it may be what just what you've wished for :) Damon

Wow, do these people know how to tease us or what? I know that I saw at least two comments telling them to hire Mark Drew (and mine was one of 'em). I also saw quite a few things mentioned that I believe the CFEclipse crew is already working on (at least in R & D). Tell me, what do you think?

(CF) Eclipse RDS Plugins: First Impressions

Wed, 26 Jul 2006 00:01:00 -0400

OK, been quite a few posts out there, within the CF community, about how you can download the ColdFusion RDS plugins for Eclipse (Well, CFEclipse). Now, if you have Flex Builder 2.0 then you already have it. At least I think you do, it might be an option during install, but either way it's available to you with Flex Builder 2.0. But, you can also go to that first link in this post to download it by itself. Install is pretty cut and dry, but you kind of have to search a little to find out what to do next.

First things first, go to your Window|Preferences, select the new RDS Configuration option, and fill in your server's details. Once you've done this you can go to Window|Show View|Other, expand the ColdFusion option, and select RDS Dataview. Depending upon where you put your 'views' panel (mine's at the bottom, which I think is the default) you will now find the new tab. Expand the server, expand a database, expand 'Tables', right click on a table and select ColdFusion Wizards > Create CFC.

OK, let me give you the good news up front. This wizard will allow you to automatically create Bean, DAO, and Gateway CFCs for your table (anyone remember Sean Corfield's Data Persistence Session at CFUnited?), saving you hours of coding work. The bad news? They aren't perfect, and will require some tweaking on your part.

"Cutter, they were gonna have to be tweaked to begin with anyway, right?" Well sure they were, but they could have been a little further along from the start. I'm not going to lay out all of my grievances here, I'm still really excited to have this to begin with, but I do want to throw out some of the things I really thought could of, should of already been here:

Consistent Coding Style

This wizard generates three different CFCs, with very different methods and approaches (even within the same files). It's just me, but coding consistency is important. It makes code easier to read, follow, and maintain. So why is it that, in certain places, a cfset tag will have the xml closing style, while in others it will not:

This is all over the place in the generated code, even in the same template (or function block). There are even inconsistencies in the code indentation (another necessary thing for code readability).

Odd Wizard Output

Like the drop down that let's you select 'public' or 'private' for your 'Property scope:' Let me tell you what I expected and what I received. I thought that, in selecting 'private', all of my setter methods within the Bean would have an access type of 'private'. But that didn't happen. In fact, I don't think it affected anything at all (as all of the methods are 'public' on generation.)

Odd Code

I know that a team of developers probably built these extensions, but who would have thought that they could all be so different? For instance, why does the Bean have an init() method, while both the DAO and Gateway objects do not? "Well, Cutter, maybe it's because the DAO and Gateway don't have any properties?" No, that can't be it. The DAO and the Gateway objects both have database calls, so they must have a property for the datasource name, right?...Hey, why is there a DSN hardcoded in to the cfquery statements? Doesn't make for a very portable object, does it?

Within the DAO objects: In the read() method, why doesn't it just loop the returned query's columns with 'set' statements, rather than writing each one out line by line? Wrap it in a try/catch, with an empty catch, and it'll skip any column that doesn't have a matching setter method without causing a hard error or interrupting the flow (There does appear to be a good reason for not doing this, but that's another item you'll see below.)

And what about that create() method? Pass in a bean object, set variables with the value of the 'get' method of each property, and then pass the variables themselves in to the cfqueryparam value attributes (having the server evaluate that variable in the process [not to be confused with evaluate()] Why waste the steps?: The funny thing is, that is how it's done in the update() method.

And why do I get 'null=[bunchastuff]' on cfqueryparam tags of table columns that don't allow nulls? I don't get that? The Wizard is already reading the table's metadata to give us the column name and data type, it can't get whether it's required?

And why do I have to pass in a Bean object to my delete() method? All it needs is the ID and it's all set, why waste the memory to allocate for a whole object?

And then we get to the Gateway. Here's a 'GetAll()' method, that returns the ID of all records from the table and loops through the recordset to create a bean object instance for each record, placing the beans in an array. Whoa Baby! What's up if you have several thousand records in that table? "Hey man? Why'd my RAM utilization just go through the roof?"

OK, so maybe I'm bitchin' too much. Or, maybe, these a several small points. Why doesn't the the read() method in the DAO loop the columns and dynamically create/fill the new bean? Because the data validation is directly in the set() methods of the Bean. Now, I would put these things in a validate() method of the Bean, which is always called prior to the 'save()' method of the Gateway, but that's my preference. Just like I would rather pass a struct (like the 'form' scope) into my create and update methods, rather than an actual Bean object. A matter of preference.

So, if my Java skills were greater, and you could decompile a .jar and .class files (Which I don't think you can, last I checked, but Mark will set me straight I'm sure), then I'd try to make the changes myself. But, that's not possible, so I guess I'll forward this post on to Adobe for a possible update (as soon as I figure out who to send it to). It would be nice if there were some sort of XML file one could change, in order to create our own preferential style of code, but that's probably asking for too much. Maybe a consensus on developer's views of several "Best Practice" implementations? Or maybe Adobe should just give the current code to Mark Drew, pay him some dough (that'll get him to MAX, an expensive trip for him when he doesn't get paid for continuing development on the tool we use everyday), and have him find out what we'd like and code it? (Side caveat: I am not saying that Mark would. I'm not his booking agent, nor his headhunter, nor him, so I'm just offering that as a possible solution for Adobe to consider. I would not expect Mark to work on any feature of CFEclipse that he hasn't put on the radar himself as an item of priority [and I know he's got some really cool stuff on that radar], or if he were getting paid to do so [which would only benefit us in the end as well].)

(He's gonna kill me now...) ;)

But, overall, it's a great first step. When I ran it through the paces this weekend, using the Wizard on only nine tables in less than 5 minutes saved me hours and hours of tedious, repititious coding. Sure, I had to tweak it a lot, but it still cut my workload by more than at least two thirds by doing these common tasks for me. And, unlike Reactor, I can see all of the code the wizard generated for me and adjust it directly to my needs (run an MS SQL timestamp field by Reactor and see what it does for you). I can now take my CFCs and plug them in to a Model-Glue app, a Mach-II app, a Fusebox app, or just roll them in to my own architecture (Hey, where did that link go to?) if I wished.

What do you folks think? Have you played with it yet? What's your take? How would you do it differently?

CFUnited Wrap Up Pt 1: CFEclipse

Thu, 06 Jul 2006 08:43:00 -0400

Well, I downloaded the CFEclipse beta plugin, and installed it into a fresh install of Eclipse 3.2. I opened my workbench, set up a project, opened my perspective and everything broke. CFEclipse has always been a great tool, but this beta is way too early, and should probably be scrapped to start over. OK, jokes over. Mark Drew will quietly chuckle at this post, the last time I'll bring up this now old joke from the conference. The fact is, CFEclipse is the new phenom. Everybody loves it. Everybody was talking about it. Every session showing code examples was using it. And everyone from Ben Forta to Sean Corfield to Joe Rinehart (etc., etc....) was telling us "If you're not using it you should be". Those of you who've been following this blog know that we spent quite a bit of time with Mark while in Bethesda. Aside for consuming fairly large amounts of alcohol, we also had the opportunity to give Mark some feedback on CFEclipse features, for which he was furiously taking notes for later updates. In Mark's (paraphrased) words, "This is great. I spend so much time working on CFEclipse (in Java) that sometimes I lose site of what features might be necessary from a (CF) development standpoint." Needless to say, downloads of CFEclipse saw a sharp increase during and after the conference. In a small bit of irony, during the Flex sessions the presenters kept saying "use CFEclipse" for CFC editing, yet Flex 2.0 does not yet work on Eclipse 3.2 (several key features break, including the RDS support), yet the beta ("Beeta", as Mark would say) only works on Eclipse 3.2. I asked Mike Nimer about this during the Flex and ColdFusion Integration session, at which point he stated that an update to Flex would be "a priority." (Side Note: the Eclipse Callisto release, an update to 3.2 for the IDE, as well as several key related projects, came out two days after Ben's keynote announcement about the release of Flex 2.0) The good news? For those who care to do so, Eclipse runs standalone, so you could run 3.1, with the current stable version of CFEclipse, if you wish to do Flex development, while also running 3.2 with the CFEclipse beta for straight CF development. Some features of the beta? Language versioning per project for tag insight and code complete (courtesy of funding from NewAtlanta), Word Wrap (yeah!), and CF dev toolbars similar to those of Dreamweaver or Homesite (for those of you who like that sort of thing). And, straight from the CFEclipse session, the one really cool feature that's been there that most never knew about? The scibble pad. Look it up, you won't regret it.