The story all begins when I took over the Coldfusion platform support for, I started to find myself spending a bit of time watching cfstat on the servers to get a feel for the current status of the machines. As we had multiple servers (then 4, now 6) and only being able to get to cfstat directly on the machine, this was not really practicable.

What I really wanted was a little desktop application that could give me the headlines of cfstat for as many servers as we had, all in an easy to digest format, the result is the CFStatShot Yahoo Desktop Widget.

Great it worked! So I move on to writing my test case (yes, yes I know it should have been the other way around).

So I write a few tests to give different date stings in the dump format and then compare them against Coldfusion objects. All of them fail.

I dig deeper, dumping the dates and get the following:

strDate:

11-APR-07

expectedDate:

{ts ‘2007-04-11 00:00:00′}

actualDate:

{ts ‘2007-04-11 00:00:00′}

dateCompare( expectedDate, actualDate, ‘D’ ):

1

That’s strange the string representations of the dates sure do look the same. So I change the dump to dump the values from the date object (the day, month, year values) and get the following:

strDate:

11-APR-07

expectedDate:

{ts ‘2007-04-11 00:00:00′} — day: 11 month: 4 year: 2007

actualDate:

{ts ‘2007-04-11 00:00:00′} — day: 11 month: 4 year: 7

dateCompare( expectedDate, actualDate, ‘D’ ):

1

Ok, now I see – it’s seeing the year from the date string as 07, that’s fair enough, but why is the string representation showing 2007.

With a bit more digging (trying to create random date objects) it appears that before the year 100 Coldfusion doesn’t actually create a date object with the year you asked for but instead guesses you meant either 20xx or 19xx with the cross-over point being 30. Any date objects created with a year of 1-29 will return 20xx and any between 30-99 will return 19xx, any other positive integer will return the provided year (negative integers do something weird).

At least I’m not trying to write something that will need to handle years older than the year 100, but there go my plans for the killer web application to manage museum artefacts.

Note: This is where someone points out the CF documentation (on that hideously slow reference site) which says exactly what I discovered (but in a more concise and articulate form).

However we have been thinking that to really get things moving forward quicker we might move to Coldfusion. We currently have a dedicated server which runs my family of sites which is a LAMP box running.

So I have an open question to any of my readers, what would you guys see as the best option moving forward:

1. Coldfusion installation on our current web server – I have no experience of installing CF on Linux, I don’t know what kind of overhead it has etc.
2. Coldfusion hosting, if this is an option we want it to be flexible but as inexpensive as possible – any suggested hosts.

This is just a whim at the moment and I haven’t performed any real research into the above options (yet) so I thought I’d just throw it out and see what other people think.

Web Hosting in Canada, 24/7 Toll Free Support. Starts $3.95/m. Canadianwebhosting.com

I’ve seen a few thoughts about how to best work around this, such as the above post on Java vs CFC instantiation by Mark Drew and the ideas presented by Peter Bell with regards to iterating business objects which I’ve mentioned before.

But to be honest I’ve not explored either of these in any great detail, although I really wish I could devote some time to looking at them.

Another, and easier and more instant, solution appears to have been suggested by Brandon over at devnulled in his post on how the Coldfusion compiler works in the following aside:

A related thing to note that he doesn’t cover is how much faster it is to instantiate objects in cfscript rather than CFML on a percentage basis. Just some food for thought. I can do a follow-up post on this in particular topic if anyone is interested.

Of course we’re interested in a follow up post. After reading this I spent a few minutes testing this out with a few different CFCs from our model; beans, gateways etc.

I was only looking at the average time of instantiation in either 100 and 1000 iterations and although I did see a tiny improvement in the average time in cfscript I won’t be going out and rewriting all the code that uses cfset to instantiate CFCs just yet.

I’m hoping that Brandon has some hidden trick or information up his sleeve and I’m dying to read a post on it (and I’d say as much in the comments on this post if it would let me, every time I try it doesn’t get added to the post) and find out there really is a marked difference between the two.

Personally I find it easier to read ECMAScript syntax rather than the tags in Coldfusion, so I use it wherever I can already. But if there is a speed benefit for using cfscript when instantiating CFCs then I can use that as leverage to get the rest of the team at work to start to use cfscript wherever possible. Which would be nice.

Update: I’ve just found a post on the Coldfusion compiler over at Absolutely No Machete Juggling that goes into detail about exploring the differences between the resultant compiled Coldfusion code in a simple test (not related to CFC instantiation). The important notes that may apply to CFC instantiation appear towards the bottom of the post:

So there you have it, the SetVariable implementation is slow…

CFScript [when compiled] doesn’t use SetVariable, so if you’re doing heavy loop code like this, I’d recommend writing it using CFScript rather than CFML.

I decided to try see if Java had any way of handling SFTP and potentially writing a CFC wrapper for it myself, but luckily Michael Traher over at Social Points had already implemented a wrapper for JSch – Java Secure Channel.

It’s fairly straight forward to use, but could do with a bit more inline comments to help clarify the interface. One thing to note is if you need to use a private key to log into the SFTP server then make sure that it is in the OpenSSH format, which with PuttyGen was a really quick thing to do once I’d figured out the problem (by looking at through JSch mailing list archive.

So now the task creates the files and uploads them reporting the success or failure automatically.

Fast forward to today and I switch sites in IIS to test something else and suddenly IIS is serving the Coldfusion pages as octet streams and the browser is asking if I want to save or open them, this is not good. So I go through the whole process of removing and adding CF again via WSConfig, no luck. I manually restart IIS and then Coldfusion, still no luck. I go back to the first site, the one with the flash forms, and that’s not working anymore. Hmmmm.

After a bit more fiddling I figure out that if I type in the exact URL of a template (e.g. index.cfm) everything works fine, the problem is only occurring when IIS is trying to hit a default document that is a CF file or catch an error that redirects to a CF file; which is odd.

I spend what seems like hours (in between other things I’m doing) spent in an endless circle of removing and re-applying the CF configuration using WSConfig, restarting CF, searching on the web for ideas and similar problems, restarting IIS, restarting the machine, shouting at the monitor and throwing things (not necessarily in that order). I even tried searching for "WSConfig is rubbish", which returned nothing at all – which isn’t very helpful.

I eventually found a very handy post by Peter J. Farrell, as an aside I’ve always wondered what makes a person choose to use one or more of their initials in every day use – I guess for actors and writers it has something to do with previous artists and to avoid confusion with them. Anyway I’m getting distracted from the point; which was the post by Peter that saved my afternoon. Although the problems described didn’t directly relate to my problem, I wasn’t getting the same error messages and I’m using IIS, it also didn’t appear under a search for "WSConfig is rubbish" but I gave it a try.

Two minutes later me, Coldfusion, IIS and my monitor (and possibly my work who colleagues may have been thinking I was slightly unhinged) were happy once again.

So if you have any sort of problems with WSConfig, be sure to give Peters post a try, it could be the difference between sanity and eating cereal from a slipper – with a comb.

The topic in question that got me shouting at my radio and making fellow commuters stare ahead more intensely than before was Object Orientated Programming, more specifically the use of some of the basic data OO patterns within Coldfusion.

I must state here that I am still a long way behind catching up with the backlog of my Podcasts and if the points I raise here have been raised or addressed in later editions of the Podcasts in question then I apologise for any overlap of thoughts or information.

Anyway, back to the post.

I’d just finished listening to Helms and Peters Podcast episode 26, Groupthink, in which Hal has what you could call a little rant about developers who use only the most basic OO design patterns, mostly being the data-centric patterns such as Data Access Object, Value Objects/Data Transfer Objects/ Beans & Gateways and declare themselves to be OO developers.

I couldn’t have agreed more, although these patterns are the workhorses of most web applications they are a huge step away from really digging into the domains you are dealing with and modelling them effectively within your software. They are in fact patterns that are used very heavily in the applications I deal with, but they are so boring and repetitive that I make as quick of an overview of the patterns when introducing our new developers at work to our applications. It takes two minutes to get your head around them and then move onto the more interesting patterns.

As an aside, this is also part of the reason I am researching CakePHP for my personal PHP based work and Reactor for my Coldfusion work. I’m really sick of creating DAOs in particular, OK so I’ve got the process down to the bare minimum in CFEclipse using snippets, and I’ve got a sweet generic persist() method in the DAOs that, combined with the dirty marker pattern, deals with whether to call the create, update or delete method as appropriate, but I’ve had enough now, I’ve got better things to do with my time.

Back in my car I move onto the next Podcast on the list, which was the Coldfusion Weekly Podcast Version 1.10 Safari Edition where the topic was a design pattern Safari; an introduction to design patterns covering DAOs, Gateways, Beans and Services/Managers.

As an introduction to design patterns these are probably the easiest to cover, as they are so simple and anyone who creates a web application will probably need these. It was kind of a co-incidence that the subject of these two Podcasts overlapped a little. The Podcast was a quick and easy introduction to design patterns and why to use them and as I say covered a few of the basic ones.

Now to the real point.

Talking about Beans and persisting data the Podcast covered the common argument of "this seems like a lot of overhead to just get at my data" by making the following points:

• Getters and setters give you lots of control over access to the data.
• You may want to make some information read only, which can be accomplished by making the setters private.
• You may want to restrict access to data for certain users/groups etc. (although I believe the Bean shouldn’t really know about that).
• Validate data passed to setters.
• Allows Bean composition. A Person Bean could contain one or more Telephone Beans an Address Bean etc.
• Beans and especially composite Beans are consistent with the way you think about the data relationships in the real world (this is touching on domain modelling).
• Easier to swap persistence methods (e.g. database or file system etc.), this was covered when they discussed DAOs, but also applies to Beans.

There are some points I would like to add to that list:

• The rest of your model and application(s) don’t need to know the structure of the database, how to deal with result sets from the database etc. just the interface of the bean.
• Your getters can encapsulate regular data manipulation tasks. For example say you have an Address bean with the fields: address1, address2, city, county, postcode. A common requirement for addresses is to format them as a concatenated string (usually with commas and spaces) while ensuring some of the optional data (e.g. address2 or county) is handled correctly. In my opinion this kind of functionality really deserves to be encapsulated in a method on the Bean such as getFullPostalAddress().

So this was great, a fine example of defending what some beginners in OO see as a un-necessary overhead to "just get at the data", fantastic – if I wasn’t sold on Beans before I would have been after listening to that.

After that they skim over DAOs, again giving you the right amount of information about DAOs.

Next is where it all went wrong for me, Gateways. They jump in head first stating with CF they return queries from their Gateways rather than arrays of Beans because it’s easier and quicker (CF does have some sweet query iterators) to use these rather than Beans.

"Hold on!" You may gasp (or shout at your car radio). "Haven’t they just spent the last few minutes extolling the benefits of Beans, their encapsulation of data and powerful yet simple interfaces to said data etc.".

If you didn’t, you should have and I believe that you would be right to. Not only do we lose all those benefits of Beans that have just been covered, we now have the possibility of having to write two types of views (in a Model View Controller based application) to do the same thing depending on whether we’re dealing with a single entity or multiple entities and lots more problems. It’s all so messy.

So why are we in the position where it’s become common practice to have Gateways returning query objects willy-nilly in CF and why did we lose sight of the benefits of Beans so quickly?

Well with OO in CF we currently (fingers crossed this can be resolved) have a small problem, instantiating objects adds quite a lot of overhead. I can’t remember the exact figures, and it probably isn’t a consistent amount for all objects, but somewhere around 40ms is something that I remember being quoted to me. This is obviously a problem if we want to return lots of populated Beans from a gateway as an array, just instantiating 10 of them will add nearly half a second to your execution time.

This wasn’t really covered in the Podcast but really deserved to be. Before I continue I must say that I am myself guilty of using Gateways to return query record sets, basically because I didn’t know any better, but it is something I intend address in the near future.

So what can we return from Gateways in Coldfusion?

The absolutely fantastic (and prolific) Application Generation blog by Peter Bell offers what I believe to be the best solution I’ve seen so far, Iterating Business Objects.

The basic principle is you have a Bean (Business Object) that knows how to take a query from a Gateway and then iterate over the query populating itself on request. This way we retain the power of the Bean but don’t add the overhead of object instantiation and everyone is happy, although it’d be nice to retain something as simple as <cfquery> for the iteration.

I was planning to say a little about this idea and link to all these fantastic posts from Application Generation and now seems the perfect time to do so. I’m not going to re-hash the detail from the posts but they are all definite must reads for any CFer:

• Returning data Beans vs Queries
• An Iterating Business Object
• Real World Benefits of Iterating Business Objects over Recordset
• Snippets The Base Iterating Business Object
• Snippets Displaying an Iterating Object

I hope this post doesn’t come across as me bashing the Coldfusion Weekly Podcast, because that was not the aim – it’s one of my few regular Podcasts I listen to. My aim was only to point out that when it comes to Gateways I think we can all do a lot more to work around some of the limitations of CF without losing the benefits of Beans.

First of all, wow, Ben Forta – so it was just a passing mention, but for anyone working in the CF or Flex development fields Ben Forta is a very important and influential figure. Secondly, I still find it amazing how quickly the web moves, I received the final copy of the interview copy in my inbox on Thursday afternoon and by Friday morning it had been picked up by Ben Forta and relayed to myself via Martin.

Finally the interview on Web Wire appears to have been edited a little, I’ll try and get my hands on the original and post it here.

I simply spent the weekend watching the demo videos & running through all of the tutorials and then started to play around with the Coldfusion/Flex connectivity and believe I grasped a large amount of how to work with Flex 2.0 within that time.

I had looked at the Flex 1.5 examples previously but never took a look at their implementation, I understand that there have been substantial changes between 1.5 & 2.0 and the Flex Builder alone is a beautiful example of the power of the Eclipse IDE.

The power and simplicity of Flex itself is outstanding and I have 3 areas in mind at work where we could take advantage of Flex, combined with our existing Coldfusion domain models, and really see the benefits shine. Indeed I spent the following few days in work gushing about Flex 2.0 and all of it’s benefits, which luckily was contagious with my colleagues, I guess this post is simply a continuation of that.

All I can say is I can’t wait to get my hands on it for a full project, the potential of using Flex for a certain project that I have previously been apprehensive about has actually made me really excited about it.

It hadn’t really occurred to me until that moment – and I’m not sure if I’ve ever read anything about this, but data types in Coldfusion extend Java data types; in the case of arrays that is java.util.Vectors.

This gives us access to all the native methods that Java has available on those data types and for my requirement that meant the nice and simple way to ensure that two (Coldfusion) arrays arrayA.equals(arrayB) are the same.