Every now and then you may find yourself doing AJAX requests in a model-glue application.  One of the parts of this is a page that returns a lump of JSON encoded data.

Now, imagine you are doing this in development and you may have the model-glue debugging turned on.  if you do, the browser won’t understand the JSON data due to all the MG debugging junk appended on the end of the page.

So, how do you get round that issue apart from turning off debugging in your config and running it again (a bit of a pain)?

Well, simply set request.modelGlueSuppressDebugging to true and you’re rockin’.

So, what’s been going on with Feed-Squirrel recently? Well plenty thanks….

You may have seen a few days ago that Ben Forta had posted that feed-squirrel.com (my main aggregator site) had migrated to CF8. For me, this is a key step that the site needed to take in order for me to try some new and interesting stuff in the near future. But enough of that, let’s get into the nitty gritty of what’s changed…

1. Overall performance. Hopefully regular users will have noticed significant increases in the performance of the site. This is for a number of reasons
• Coldfusion 8. Although it’s difficult to quantify, it’s make an improvement to overall speed.
• Caching improvements - Lots more of the site is cached, meaning a lot less work required on the data tier (which is one of a not so nice parts of an aggregator)
• No more Model-Glue - Now that may suprise a lot of you, but I’ve effectively gone for the anti-framework. All parts of the site are now built in a fairly bespoke way suited to performance and maintainability. There is still a central data object but everything else is split out in a very lightweight MVC style. This has meant that I have been able to get rid of a lot of the bloat that a complex framework brings, and reap the performance benefits. Also, I never really got on with Model-Glue. I found it got in my way.
2. CFFeed. This tag alone makes my life a lot easier. Unless you’ve ever tried to write some RSS aggregation code you would not beleive how many different feed dialects there are out there. Out of the 1,200 odd feeds the site aggregates, I’ve come across around 1,200 different ways of presenting feed data. It would appear Atom vs RSS is only the top of the iceberg. You may notice that some previously dormant blogs are now aggregating successfully….This is down to CFFeed.
3. CFThread. Another superb tag. Right down in the bowels of this site is some import code, this code runs through every feed on a regular basis checking for new items. Due to the fact there are so many, CFThread now means I can check all the feeds on a more regular basis without having the long running requests that I previously would have had.
4. CFLayout. Check out the “Watched Feeds” and “Create Custom Category” pages. These used to be one huge list of feeds. Now, by using the CFLayout tag, this page has been reduced in size greatly, and even makes it easier to find what you are looking for.

So, all’s good then. Well, as with all migrations there are small problems. I had three significant ones which were:

1. Corrupt Table.This is an error that Coldfusion started returning was load was placed on the server. After some quick tracing, I tracked down the problem to cached queries. It appears that sometimes a cached query can go a bit screwy and force the server to return this error every time the cached query is used. Strangely I found that the error was still returned after I removed the cachedWithin attribute from the query. The only way I could find to get of the error was to flush all cached objects from the server with the CFObjectCache tag. Unfotunately I have not seen this since so I can’t really tell you anymore.
2. Cannot create a new thread because the task queue has reached it maximum limitI started getting this error on the importer. A server restart was the only way to fix the issue and I’m a little unsure as to what the problem might have been. After thinking about it for a while I beleive that there is a thread limit built into CF and that that threshold had been met with entirely unresponsive threads. It would appear then that once this thread pool is full, CF just returns this error.
3. CFFeed limitationsI said before CFFeed is a great tag, and it is, but for me there is one limitation. CFFeed can go off and retreive feeds for you, but for some reason Adobe have left out some of the key functionality of the CFHttp tag which is useful from a resilience point of view. Primarily is the timeout attribute - that the tag should stop trying to read the feed after x seconds. Secondly, CFFeed doesn’t play well with Http Authentication. Whilst in development, I uncovered a situation whereby CF was sat spinning a thread due to the fact that the CFFeed tag had tried to retrieve a feed that required Http Authentication. Instead of failing out as you’d expect, CF just sits there for ever and ever, never timing out, and never returning an error. As far as I can tell the only way to kill the thread is via a server restart. There is a workaround though. Simply use the CFHTTP tag to retreive the contents of the feed, before passing it into CFFeed to deserialize.

So, overall hopefully you guys find the site is more pleasent to use and some small touches make it more useful to you. When you consider that the site’s ground up re-write from blank to now took me around four hours, thats not bad going…

Now, on to the new features. Watch this space….

I’ve just been taking a look at a well-known framework that deals with command-driven code. Whilst having a read of the docs and seeing what’s what, I was thinking “this sounds handy, this could solve a lot of problems”. I then installed the framework, and was stunned when I was then looking through a multi-file/component lump of code that did a “Hello World!” example. Sure, these frameworks don’t shine when doing simple examples - but I am having trouble seeing where most of the benefits of frameworks lie.

A lot of these frameworks deal with abstraction of code so that code A doesn’t directly use/know about code B etc etc, when in reality what you end up with is the big bunch of files passing all sorts of variables and objects around to acheive things that could be written in Plain Ol’ Coldfusion (POC) in a matter of a couple of lines.

For instance, proxy objects. Why create code, that wraps other code when you could just make the location of the original code a configuration variable? Another one - why spend ages making a framework understand complex objects in configuration when again, you can just write it in POC nice and quickly without having to get bogged down in a framework?

Personally, I think we had it right around Fusebox 3-ish times. A load of MVC code all based around a central controller, and a config file (which was CF). No XML, no gateway objects, no framework loading, just a straight forward bunch of code that was easy to read and understand, simple enough to be Agile, and best of all extendable in whatever way you wanted (you just had to write the code).

Now, I’m not dismissing frameworks completely - Model-Glue for instance has it’s benefits, but personally I’ve never seen why anyone would want to get as complex as Mach-ii etc. Half the time, a lot of these frameworks appear to be code for code’s sake - a way of satisfying a coder’s needs as opposed to those of a more pragmatic programmer….

Bring on the flames….

Yup, finally, Adobe have made last weeks sessions available to everyone who couldn't make the original live sessions (i.e those of us not in the U.S)

The Adobe Engagement Platform
Introduction to Developing with Flex
Introduction to Adobe LiveCycle
Building Flex Apps with Flex Builder
Flex Data Services
Building Killer RIAs? Meet: Adobe's Next-Gen Technology
Architecture and Overview of Adobe's Security Model
ColdFusion Powered Flex
An Introduction to Adobe LiveCycle Workflow and Qpac
ActionScript 3 for Flash Developers
Looking for IT Agility, Sizzling Apps & Fast Processes
ColdFusion and Model Glue
Using InDesign Server with Flex
Building Applications using LiveCycle and Flex
Flex and AJAX Better together
Smart Client Architecture and Processing Models

Does anyone know whats happened to Model-Glue.com? It's not looking too healthy right now.

Over the last few days, you may have seen people talking about a performance test that Webapper have run against a few of the more popular CF frameworks out there, namely Model-Glue, Mach-ii, Fusebox 4.1. Also included was a homegrown app from Simon Horwith.

The results? Well, not so bad, even if the showing from MG was by no means complete. As it turns out, after some more testing, Joe Rhinehart, the author of MG, has found a couple of low level bugs in the framework. Nothing drastic, just some bits that could be a bit cleaner.

So, the framework previously known as MG 1.1 is getting a revision. 1.1.01 is in the pipeline (and also in the MG Subversion repository for anyone wanting to test it).

I've just been taking a good long look at the framework Model-Glue by Joe Rinehart. I have to commend Joe on what he's acheived as I am very impressed.

I have come from a very procedural background, not really even taking the time to look into OO before CFC's came along, and only then taking a cursory look. One of the standout things about model-glue for me is the fact that you have absolutely no links between the different parts of the application, which is a complete contradiction to almost everything I have done in the past.

For me, this single point alone is enough reason to consider moving to a framework like this fully, especially when you consider the power then provided to you using these code units combined with CF(C)Unit and CFEclipse. These tools in conjunction with one another should give you one hell of a reliable, extensible and maintainable set of applications.

Now, I will admit, I haven't got all the way through the quickstarts yet so there are few question marks outstanding in places that I need to figure out for myself. Hopefully, I'll get a chance to blog about these when I can.