Many Sites, One Codebase

The ultimate of reusable code: using one codebase to serve many sites. Not copies of that codebase mind you, but one actual set of code templates. Update a template to fix a bug or add a feature and...? Presto! You've just updated X number of sites at once. Genius! Or is it?

[More]

New Book: Learning Ext JS 3.2

I've been pretty busy this year, starting with my new position at work. And, having worked on major side projects the last three years running, I also took my after work time to spend some overdue quality time with my family. But, I did make time to work with Shea, Colin, and new author Nigel White, to work on the second edition of our Ext JS book, now titled Learning Ext JS 3.2. Released last Monday by Packt Publishing, our latest book brings Ext JS developers up to date in working with the 3.x framework, updating the content to cover many changes to the library as well as introducing several new chapters on key bits about Menus and Buttons, Plugins, Charting, and Ext.Direct.

Sencha (formerly Ext LLC) released Ext JS 3.3 on the same day that Learning Ext JS 3.2 shipped from Packt. There are several new and exciting features added in 3.3, but the core content of the book still aligns with the core of the framework itself, giving developers the tools and information they need to get off the ground running. There were several important changes to the framework between the last book (finalized just before the release of 2.2) and this one, and it was important to get that information out to those ready to learn. In the new chapter about Ext.Direct, I dissect the ColdFusion Server-side Stack, written by Sencha's Aaron Conran, to give the bare bones info needed for writing one's own server-side data marshalling services, going through the pieces step-by-step. Changes to the Data package were just one of the reasons to write this book. I know that Colin, Nigel, Shea, and myself, hope that everyone enjoys our latest work.

Introducing Sencha

Great things are coming. Great things are here!

On June 14th, Ext JS LLC rebranded as part of their announced partnership with the principles of the JQTouch and Raphael projects, creating Sencha. The Ext JS library is still one of their major offerings, but they have also created Sencha Labs as a repository of various Open Source Projects under the MIT License (Like JQTouch, Raphael, and Ext Core). Great things were on the way!

Having David Kaneda (JQTouch) and Dmitry Baranovskiy (Raphael) join forces with the Ext JS crew is huge, and really plays well in understanding a series of recent blog posts around HTML5, CSS3, and what HTML5 means to developers today. But, it gets better.

This morning, Sencha launched their first joint product in public beta, Sencha Touch. Sencha Touch is a cross-platform mobile application framework built to leverage HTML5, CSS3, and JavaScript. It gives you the same sort of consistent API that you've come to expect from the Ext JS team, with a familiar syntax, great documentation, user forums for support, and many samples included with the download to help you learn. I've had the opportunity to preview this code for a while, and it is outstanding work. There will be some interesting apps to come out of this.

The future looks bright for Sencha, and I can't wait to see what they do next. Judging from their post on the rebranding, my prediction are changes to ExtDesigner (possibly to become SenchaDesigner), that would allow a developer to build both Ext JS and Sencha Touch interfaces from the same tool. My guess. (Man, that would be really cool.)

My CF + ExtJs Preso for cf.Objective() 2010

ColdFusion + ExtJsAttached to this is my slide deck and sample code from my ColdFusion + ExtJs presentation here at cf.Objective() 2010. Overall it seemed to go really well, despite the typical technical difficulties, and though Ray said I needed to be a little more introductory (Thanks Ray. I appreciate the feedback.) I heavily commented the JavaScript in my source code, so hopefully that will help to fill in the gaps for people. If anyone has any questions, feel free to use the contact link at the bottom of the page.

I want to shout out to Aaron Conran of ExtJs, for providing me with a license for their new ExtDesigner to giveaway in my presentation. I pinged him last minute on this, and he really came through (Hope you like it Lance. Drop me your info to give back to Aaron.) For those who haven't checked it out yet, it's a fantastic tool, really well done, and more than worth the small price tag on it.

On a side note, I'm using a "work-in-progress" version of CFQueryReader in this sample. I'm in the process of refactoring to support some advanced features of Ext.Direct, and the new version will only be compatible with 3.2 and above. When I put it into SVN I'll add some notes on which revision is the cutoff for previous versions of ExtJs.

Update: I've added notes to the readme.txt file of the sample download with instructions on how to make the examples work in ColdFusion 8 as well.

I Am Speaking at cf.Objective() 2010

I'll be speaking on building applications with ColdFusion and ExtJs at cf.Objective 2010. I was very honored to be asked to submit a topic alongside so many fantastic speakers and developers. I'll post more as the details are refined.

Can We Extend the ColdFusion Server

I love playing around with new toys. So, I'm ecstatic now that ColdFusion 9 has been officially released to the world, and even more so after what I'm about to tell you. Oh sure, I've been playing around with the betas, but mostly in testing the cfajax/ExtJs 3 upgrades (and I'll be posting more on that in the coming months). Time has been somewhat limited for me, so playtime has had to take a back burner. But, I wish I had gotten into this a bit sooner.

Yesterday I finally got around to working with some of the new cfscript implementations. I find these upgrades to be one of the key features for me personally. One, It's a faster coding style for me. Two, I was getting tired of bouncing between script and tags. Three, I really like the economy of code associated with script, finding it to be far less verbose. So, I'm lovin' the fact that I can write all of my CFC's, including my Application.cfc, in pure script. Now I can keep the tags with the display. But, as someone pointed out to me in a recent comment, there are still a few tags (anyone know which ones?) that haven't yet gotten script implementations. What can we do about that?

So, in diving right into playing with script enhancements, I ran into a few roadblocks. Minor errors, stemming from me not properly understanding the implementation. Now, the first place I went was to the documentation. Ray Camden keeps saying to me "Why don't people read the documentation?" I'm one of those that agrees with him. Yes, the documentation has some holes, and even bad examples, but you would be surpised what you can learn. (Read on, you'll see where I'm going with this!)

[More]

Scripting a ColdFusion Application

With the release of ColdFusion 9 this past week, at MAX, we finally have full parity for cfscript with all of the cf tags. I personally prefer script when writing data access and business logic. For some it might not appear to be the sexiest feature, but I can see it making CFML much more appealing to developers from other languages.

[More]

ColdFusion Ajax and ExtJs Presentation Update

I've been asked to present to the KCDevCore on ColdFusion 9 Ajax and ExtJs. This will be an updated version of my ColdFusion Ajax presentation, with new content to cover the updates and new components presented in ColdFusion 9 and ExtJs 3.0. By request, I'm going to try to keep the slides to a minimum and get down to some code.

That presentation will be next Tuesday, September 29th, at 7 PM CDT, and will be available via the KCDevCore Adobe Connect.

For those who don't know (where have you been?), ColdFusion 9 is now in public beta on Adobe Labs.

ColdFusion for the Redmond Crowd

Some time back I started receiving Visual Studio Magazine. I'm not sure why. I didn't request it, and lord knows I've tried to stay away long enough (since the VB6 days). But, being a developer with a background in linguistics, I began to read through the issues. C# looks interesting, and I'll probably play with it some, but for the most part all of it just reminds me why I'm a ColdFusion developer with skills in related web type languages (XHTML, CSS, JavaScript, etc).

Last week I received my August issue of VSM, and took a look when I got a chance. I got a number of surprises with this issue, the first one being the biggest. In the front of magazine is an 'Online Contents' section, where they list articles that are only available on the web from three Redmond Developer Network sites: Visual Studio Magazine, Redmond Developer News, and Application Development Trends. And, to my surprise, under the articles on ADT, the first heading read Adobe Releases First Beta of ColdFusion 9.

Now, here's a magazine dedicated to .NET development, pointing to sites dedicated to .NET development, highlighting an article about ColdFusion. Nice! This was obviously part of the interview blitz that Adam Lehman did just before the public release. The article talks about ColdFusion Builder, quotes the recent Gartner Report, and talks about the great new features in ColdFusion 9, with emphasis on Hibernate, full scripted dev support, as well as the Office and Sharpoint integration features (it also reminds readers about the .NET and Exchange integration features added in to CF 8.)

So, it was truly cool to see CF getting some love from the press. More so, being as the press targets a different developer market. But, it got cooler for Adobe with the rest of the issue. See, this issue of VSM was also the 2009 VSM Readers Choice Awards. Adobe took a few honors in several categories:

  • Help Authoring: Readers Choice Award Winner : RoboHelp and RoboHelp Server - Adobe Systems, Inc.
  • Web Design & Development Tools : Readers Choice Award Winner : Dreamweaver - Adobe Systems, Inc.
  • Web Design & Development Tools : Readers Choice Merit Award Winner : Creative Suite 4 - Adobe Systms, Inc.
  • Web & Mobile Development : Editors Choice Award Winner : Dreamweaver - Adobe Systems, Inc.

Great news for Adobe, and a nice shot over the MS bow. Looking over the other categories, I see potential with the release of ColdFusion 9. Here's some nice goals/targets for our favorite server:

  • Charting and Multimedia (should've been Flex hands down, but CF has it's own)
  • Data Editing, Reporting & Analysis Tools
  • Grid Components: Web (I can see it)
  • Imaging and Graphics
  • Middleware & Server Based Tools
  • PDF Tools
  • SharePoint Components & Tooling
  • Editors Choice: Most Valuable Tool
  • Editors Choice: Data Handling & Development

Thanks Adam, for pushing the tech press in areas that haven't historically gotten our message. Congrats to Adobe for it's new honors, and here's to hoping other dev communities begin to see, and recognize, the value of ColdFusion.

Request vs Variables - Which is right?

Last week I stirred the pot a bit, stating that we've been improperly using the VARIABLES scope, and it's hurting our applications. Variables placed within the VARIABLES scope do not appear to have proper Garbage Collection performed on them when we're done with them, except in the case of the scope's usage within a CFC or a custom tag. This brought up some interesting discussion, where Ray Camden, Mike Brunt, and others chimed in.

I, with very good success, have been using REQUEST where most people use the VARIABLES scope. Wait! Hold on! You have to let me finish first before you get bent. What I said was that, in the past, we placed variables into the VARIABLES scope within our base request templates, with no way of clearing those variables at the end of the request (if using Application.cfc). My thought is, if VARIABLES have no true (apparent) mechanism for release, in context of variables scoped this way in a base request, then they don't really belong in the VARIABLES scope, but rather in the REQUEST scope.

This was met with some push back. The first argument was that this breaks encapsulation. I want to begin my response here by saying the first obvious thing that comes to mind: ColdFusion is not OO! Sure, your ColdFusion application can be written in an OO fashion, but ultimately it doesn't have to be. There are even some who seem that think that maybe it shouldn't be. All of that being said, I agree with OO principles, and think that proper encapsulation is very important when developing your applications, especially in terms of portability and reuse. Just because the REQUEST scope can be used directly within your custom tags or CFC's doesn't mean that you should. I would never suggest referencing the REQUEST scope directly within a CFC, with the exception of Application.cfc itself.

So another argument was that the REQUEST scope should only be used "when (and only when) the variable must be accessible to all the elements composing the request...", going further to state that the REQUEST scope should be avoided if at all possible. Why? The rest of the argument once again comes back to encapsulation. My point is to use the REQUEST scope within the context of a request, paying attention to maintain encapsulation. Within that context, doesn't it make sense to use the REQUEST scope for variables that should only exist for the length of a request?

The ColdFusion Jedi piped in to correct me on my timeline of scope introductions to ColdFusion, and we had some back and forth over declaration of scope to clearing of scope. I contended that onApplicationEnd() cleared the APPLICATION scope, that onSessiondEnd() cleared the SESSION scope, and that onRequestEnd() cleared the REQUEST scope. Ray reminded me that Application.cfc was about application process, and that the server handled when to 'clear' variables 'under the hood.' My point back was that something has to tell the server when to de-reference these variables, and that I had always assumed that was triggered by the execution of these methods. Mike Brunt chimed in on this, saying that the application must de-reference the variables prior to the server knowing it can perform Garbage Collection on them (Side Note: he didn't come out and agree with all of my conclusions here, only seeming to agree with the logic applied.)

Possibly the largest argument overall relates to whether the apparent memory leak, when using the VARIABLES scope within a base request, is really a leak or just a byproduct? I've theorized that the intention of the VARIABLES scope was that it was to be used only within CFC's and custom tags, where it does appear to properly get de-referenced. I put out there that the only reason you were able to use VARIABLES within the base request was because custom tags were created from .cfm files as well, so there really isn't any way to restrict it's usage. Ray says that the VARIABLES scope was introduced to provide access (like StructKeyExists()) to the unscoped variables out there in the wild.I think our thoughts of 'best practice' usage should follow these lines: Using the REQUEST scope within the base request, while maintaining encapsulation.

Ultimately, I just don't know. Maybe there's still an Adobe engineer out there who goes back that far, and can remember exactly what's what and why. I do know that, after migrating several high traffic applications to these guidelines I did get a higher return on application performance. I've gotten notes from others, after reading the original post, who have done similar changes to their systems with the same improvements. What other pluses or minuses do you, dear reader, think of when considering this practice of variable scoping? Is it right? Is it wrong? Is it a sin? What do you say?

(You can follow the original comment thread by referencing the post linked below)

Previous Entries / More Entries