Quantcast
Channel: Cutter's Crossing - ColdFusion 8

Upcoming Book: Learning ExtJS

$
0
0
I've been rather quiet for quite a while now. I have a rather large side project I've been working on, written entirely with an ExtJS front-end and ColdFusion on the back-end. I'm hoping to get that into a QA phase in the next week or two. I also just celebrated my 39th birthday, my 8th wedding anniversary, my daughter is the rock star of the 1st grade (pulling straight A pluses in every category), and the holiday's are coming. On top of everything else, I'm putting the final touches on Learning Ext JS, to go to press at the end of the week/beginning of next, and due out in December. I've stayed relatively quiet on this, as I wanted to wait until PackT, my publisher, officially released information on the book. Let me start by saying that a few years ago I never would have thought I'd be doing this much client-side development again. And I definitely wouldn't have imagined me contributing to a book about client-side development. I began looking at ExtJS quite a while back, while contemplating how to "jazz up" and modernize some dated interfaces I was supporting. I thought that ExtJS was an exceptionally well thought out library of rich, consistant components and functionality. While I use JQuery almost exclusively for DOM queries and manipulation, I really didn't find enough consistency in the visual plugins at the time (this has improved with the latest round of the JQuery UI plugins). I began to learn of the real power of ExtJS, and became an even bigger fan when it was announced that Adobe was including it in Scorpio, the codename for ColdFusion 8, Adobe's first implementation of the ColdFusion web application platform since it's acquisition with the Macromedia merger. Sweet! A total win-win for me. Back in June, PackT contacted me. It seems they had started to develop a book, but the primary author, Shea Frederick, had gotten bogged down in other commitments before being able to complete the project. Some Googling on their part led them to Colin Ramsay and myself, through Cutter's Crossing. So they contacted me to find out if I was interested. The timing on this was awful. I was just starting the previously mentioned side project, my daughter was on her very first summer vacation, and just a lot of things going on. But it was too good to pass up. Aside from the fame and glory (yeah, right!), I knew that there weren't any other books out there on ExtJS, and it would be an excellent book to get out there for all the people trying to learn this exciting library. After talking the pros and cons with Aaron West, and getting sign off from my family, I finally contacted the Jedi himself, Ray Camden, to get some info on the writing process. We talked about time (a lot), commitment (more), and fame (maybe a little) and fortune (nearly none). I finally went ahead and said I would do it. So, here it is almost six months later. I took on the final three chapters of the book: working with data stores (think like browser cached data table sets), extending Ext objects to build your own custom components, and the book wrap-up, which covers all the little stuff many people miss because they aren't typically visible. Only one chapter has any server-side code (the data stores). PackT originally wanted to convert my ColdFusion examples to PHP, to conform with the rest of the book. This morning the publisher told me that they want to keep my ColdFusion examples, to show that the ExtJS library can work with any server-side technology. So, they're taking pre-order now, just in time for the holidays. Let me know what you think.

Hurdles For ColdFusion Hosting Providers

$
0
0
One thing that we, the ColdFusion community, have been hearing since the release of ColdFusion 8 is that hosting costs should come down. Adobe has been working hard to strike deals with hosting providers to provide hosting solutions that are as competitive as hosting for other server-side languages, such as .NET or PHP. They've been doing this by doing things like changing their EULA agreement to support multi-procs, disaster recovery backups, and VM hosting, as well as through special licensing deals. Unfortunately, outside forces are working against them in this.>Hosting services contain a lot of other costs, that are generally hidden to the end user. One such cost is in server administration. Any developer, setting up their own development environment, will realize that the real manual labor is spent in IIS or Apache administration, DNS management, SQL configuration and the like. Most hosting companies utilize third party software to help automate a lot of these tasks, cutting maintenance time significantly. There haven't been many software control panels that support ColdFusion. Chief among these, for some time, has been Parallels Plesk Control Panel. This software is brought to you by the same folks who bring the popular VM used on Macs to virtualize Windows. It's an extremely nice piece of software, allowing a very nice interface that integrates with several key technologies used by most any hosting provider. So you might be asking "What's the problem?" Well, the suits at Parallels have moved to a Software As A Service model, and the pricing structure has changed significantly. There were other options out there, like Ensim Pro, Helm, and H-Sphere, but Parallels bought them all up, effectively taking over the market for hosting Control Panels that support ColdFusion. Nice monopoly they have now, at least within our space. Outside of the community banding together to write their own software, their aren't any other options currently available for a ColdFusion hosting Control Panel. There is a very nice package for Windows based systems called dotnetpanel, but they do not currently support ColdFusion. They are considering support, pending justification to build it. My friend Emmet McGovern, of Full City Media (the kind folks who host this blog, and who always have my thanks), is on a mission to give dotnetpanel that justification. He started a Forum Thread, on the dotnetpanel forum, to gather feedback from the CF community for dotnetpanel to add ColdFusion support to their Control Panel product. To anyone out there that acts as a hosting provider, and even to you CFers who've been waiting on lower cost ColdFusion hosting, I urge you to stop by their site and put in your vote.

ColdFusion Query Json Custom Data Reader For ExtJS

$
0
0
Adobe's implementation of JSON return for ColdFusion is great, and frustrating. They use a non-standard return in that, instead of the expected name/value pairs, they return first a COLUMNS element, listing the column names only once, and then the DATA array of the record set values. The column names are listed in the order with which the data is listed in each array element. This is great, in the fact that the data packets are much smaller than the traditional return (traditional meaning, that which is returned by most other app servers), but the down side is, it isn't traditional.John Wilson wrote a custom Data Reader for the Ext JS library, to help with parsing the ColdFusion return. However, although it created records within a Data Store, it didn't handle the column aliasing you are usually capable of when defining fields, nor did it properly cast variables as it should. I finally had a chance to run it through Firebug, and step through the process, at which point I also really had a chance to review the custom extension. While it worked, it really wasn't using the best tool for the job. The extension extended the Ext.data.DataReader base component. The ColdFusion return basically gives you an Array of records (the DATA), and Ext JS already provides an Ext.data.ArrayReader object that extends the JsonReader. So, after some refactoring and general tinkering, I now release the CFQueryReader custom Ext data reader. Inspired by the CFJsonReader, originally writtin by John Wilson (Daemach). This Custom Data Reader will take the JSON return of a ColdFusion Query object, rather returned straight up, or via the ColdFusion QueryForGrid() method. The CFQueryReader constructor takes two arguments @meta : object containing single key/value pair for the 'id' of each record, equating to the 'mapping' of the column @recordType : field mapping object The recordType object allows you to alias the returned ColdFusion column name (which is always passed in upper case) to any 'name' you wish, as well as assign a data type, which your ExtJS app will attempt to cast whenever the value is referenced. ColdFusion's JSON return, for a ColdFusion Query object, will appear in the following format: {"COLUMNS":["INTVENDORTYPEID","STRVENDORTYPE","INTEXPENSECATEGORIESID","STREXPENSECATEGORIES"],"DATA" :[[2,"Carpet Cleaning",1,"Cleaining"], [1,"Cleaning Service",1,"Cleaining"]]} The ColdFusion JSON return on any query that is first passed through ColdFusion's QueryForGrid() method will return the object in the following format: {"TOTALROWCOUNT":3, "QUERY":{"COLUMNS":["MYIDFIELD","DATA1","DATA2"],"DATA":[[1,"Bob","Smith"],[6,"Jim","Brown"]]}} The Ext.data.CFQueryReader is designed to accomodate either format automatically. You would create your reader instance in much the same way as the CFJsonReader was created: var myDataModel = [ {name: 'myIdField', mapping: 'MYIDFIELD'}, {name: 'data1', mapping: 'DATA1'}, {name: 'data2', mapping: 'DATA2'} ]; var myCFReader = new Ext.data.CFQueryReader({id:'MYIDFIELD'},myDataModel); Notice that the 'id' value mirrors the alias 'name' of the record's field. The CFQueryReader is available from the below download link. Anyone having any issues just post a comment. You may also find information on the Ext JS Forum Post.

Learning Ext JS Released, and Getting Press

$
0
0
It's been a busy week, with a flood of feedback coming in on the newly released Learning Ext JS. In fact, I've been so busy that I forgot to tell my own readers that it was released! Peter, Steve, and J.J. all put up posts about the book coming out, for which I am grateful. Then Aaron followed after the release, with a post on the Press Release that my employer put out about my involvement with the book. Shea and Colin both have put up entries on the book, including a breakdown of the chapters. Then Shea announced it within the Ext JS Forums, which really brought some positive response, and led to the first review on Amazon.Learning Ext JS Book Cover (photo)But for me, the biggest thing about this rollercoaster was when my copies of the book came in on Friday. I was at work, but my wife calls, and she and my daughter are in tears after reading the book's dedication. When I came home that night, Teresa put the book in my hands and said "You did it!" It's an odd moment, standing there with this book in my hands, just staring at this cover with my name on the bottom. One of the coolest things. I IM'd about it with Ray on Saturday morning, who I had asked authoring advice of before taking on the project, and he said "The hard copy makes it real." So, now I'm on to finishing off a huge side project. I'm "eating my own dogfood", so to speak, as it's a rather large application with a single page Ext interface, communicating with ColdFusion via Ajax. I hope everyone enjoys the book as much as Shea, Colin, and myself enjoyed writing it. Let us know what you think.

Real Error Reporting from ColdFusion 8 Server

$
0
0
Totally stumpled on this by accident. I wrote a statement using the NumberFormat() function, and accidentally placed my mask before the value. Being backwards this threw an unexpected error, which not only told me what I had done wrong (basically told me that the value I had passed was not a valid mask), but also gave me a chart of what the valid mask syntax would be. Now, this is in my test environment, so robust exception info is probably selected (I haven't checked), but I'm wondering why I'm receiving such outstanding and informative error reporting for this function I barely use, but I can't even get the correct line number of a query error (which it used to do)?

Ext Custom Data Reader for ColdFusion: More Info

Development Ties

$
0
0
On the last day of CFUnited 2005, a group of us were out on the patio having a final drink together. I got into a conversation with Clark Valberg about linguistics. I was a translator in latter half of my time in the military, and Clark was asking if I thought my experience with learning another language had helped me in learning to be a better developer? I absolutely agreed. I have an aptitude for languages, and always have. It's something I've picked up, and I can generally get to a point where I can effectively communicate (at least on the simplest of terms) within a very short time. Programming isn't much different, if you think about it. When I first got into computing again, after leaving the Army, I was teaching myself ten different programming languages at the same time. I had a lot of catching up to do, being out of the game for so long, so I picked up some books, found online resources, and took to the task of getting up to speed. Maybe that's why there are so many talented developers outside the US. In the US, we aren't required to learn another language out of necessity, whereas in most other countries of the world (not all, but most) it is very commonplace for people to speak two or more languages. You can kind of apply this in the reverse, to some degree, as well. Those who only learn one development platform may be limiting themselves. Knowing one programming language inside and out can be a good thing, but learning others can also open a developer to new ways of approaching a challenge. I've known many developers who knew a server-side language (ColdFusion, ASP, PHP, whatever), but never bothered to learn JavaScript, or how to write well formed XHTML. To me, that's limiting. Even crippling. What are your thoughts?

CF 8 and Ext: Presenting to Phoenix CFUG

$
0
0
March 25th, at 6:30pm MST (9:30 EDT, 8:30 CDT [Phoenix doesn't do Daylight Savings]), I will be presenting to the Phoenix ColdFusion User Group my presentation on ColdFusion 8 Ajax and Extension with Ext JS. For those not in the Phoenix area, you can attend over Adobe Connect.

Ext Conference: Day 1

$
0
0
Day 1 of the Ext JS Conference has been busy. Last night I had dinner and drinks with Jeff, a really nice guy who heads up development for a group writing web based interfaces to hardware appliances. Turns out Jeff is also the guy who introduced JavaScript to Douglas Crockford, who was today's keynote speaker. Douglas made sure to recognize Jeff at the beginning of his keynote, which I thought was a nice nod to the guy who helped give him direction in his career. Douglas ran us through a brief history of hypertext, the evolution of the web, JavaScipt, and the browser wars, before touching on the future of the web, some of the things in the new JavaScript specs being worked on through ECMA, and the fact that none of it would matter for years until the browser manufacturers would implement it. He did give props to Flash, AIR and SilverLight for trying to further the web experience where it has lagged so much over the years. He also spoke about the pitfalls of security in Web 2.0 applications, and the primary culprits of those issues (the browser manufacturers). Before I go a whole lot further, let me tell you that the conference center, and their service to us, is fantastic. Held at the Ritz-Carlton Orlando, the location is beautiful with it's palm lined drives, a well groomed golf course winding around several 'water traps', and a huge pool with several fountains. The food has been exceptional, with an incredible meal at lunch, complete with salad, brazed chicken, and desert with complete table service (this as part of the conference). No buffet sandwhiches here, though a breakfast buffet would have been nice before that 830 session this morning. My room is about half the size of the one I had at the Hotel Rouge last year for WebManiacs, but it is very comfortable and service keeps it nice. The shower did flood the entire bathroom this morning and the in-room coffee is horribly weak (and small), but everything can't be perfect. I've also carried on my conference tradition of bringing a sinus infection with me, which is keeping me from the after-session activities this evening, but the concierge was able to get me covered with some NyQuil for the evening to try to knock this stuff out of me. Aaron Conran, fellow ColdFusion developer and one of the original contributors to ColdBox, delivered the session covering what has changed and what's new within the 3.0 release, which is officially released tomorrow by Jack Slocum during his keynote. A great deal of work has been spent to make the upgrade fairly painless, with attention payed to backwards compatability, improvements to overall memory management (always important), and an eye towards keeping the code lean and mean, doing what is necessary to keep code size to a minimum and eliminate any unnecessary bloat. Menus and Toolbars have been converted into true Container objects, and the only significant markup changes appear to be to the Button objects. There are several new visual components, maintaining the professional feel and consistency that has made Ext JS so compelling. Two that attracted a great deal of attention were the ListView and the Buffered Grid View. Sometimes you want the basic view afforded by a Grid, without having the need for (or the overhead of) things like drag and drop column ordering, sorting, and the like. The ListView gives you a basic grid style layout without all of that overhead, and a very trim DOM footprint as well, providing your view without unnecessary code bloat and browser memory overhead. The Buffered Grid View is a full Grid implementation that allows the browser to only render DOM for records in actual view, plus a few extra to make smooth transitions on scrolling, that automatically adds and removes DOM items when scrolling through your recordsets. The memory management improvements with this, and other changes, are very nice to see. Like the new .mon(), or 'managed on', methods that allow you to bind events in a temporary fashion, getting a proper cleanup from browser memory when that component gets destroyed. This was actually a method of Ext prior to it's 1.0 release, and has been heavily requested for this return. Being the server-side guy that I've been for the last decade, the important new components came to the Ext.data package, with the addition of the Ext.data.Direct and Ext.data.DataWriter classes. Direct provides the ability to marshall your remote service call definitions into one container, calling your Ajax data requests from a centralized location with the ability to make multiple commands through a single Ajax request as well as call listeners on specific actions performed by Direct. Chris Scott did a presentation on Direct this afternoon, explaining how the developer has to create a server side Router to which Direct can attach it's requests, and showing us all a nice and very simple example (even if it was written in Ruby). The Ext Team provides a Reference for development of Routers in a number of server-side languages, including ColdFusion, PHP, Ruby, and .NET. The DataWriter class, covered in more depth in a future session, does for POST requests what the DataReader does for your GET requests, allowing a developer to define your routing of requests to send data back to the server. The combination of these classes with the existing classes of the Ext.data package really improves upon the power of using Ext with any server-side technology. I was able to see the presentation on the Direct class because of a snafu with a scheduling change of the presentation of the Ext.air package. Originally these two sessions were the one conflict in my schedule, but they moved the Ext.air presentation session up a time slot (a change I didn't know of until after the fact) which allowed me the opportunity to sit in on Chris's session. Luckily the presentations are being recorded and are supposed to be available online after the conference. I'm glad they're doing this, since I had to leave during my final session of the day, on Ext.Core, due to the sinus issues that progressively worsened through the day. The Ext.air session is one I am very looking forward to watching. The members of the Ext Team are a great group of guys. Abe, again, congratulated me on the book, and invited me to sit in on the Industry Experts panel tomorrow. I've had several people say they wished they had brought their copies of the book so Shea and I could have signed them for them. One attendee asked why PackT didn't have a booth setup somewhere, which is when I first noticed that their don't appear to be any outside sponsors for the conference. Ext appears to have financed the conference solely through the registration of the 200+ attending, which is pretty impressive considering the facility and it's services. On another note, ColdFusion has been publicly mentioned in several presentations, and with so many different server-side programmers represented here it is refreshing to hear so many comment that they should give ColdFusion a hard look. And with that, I'm going to pack it in for the evening and pray that the NyQuil does it's job to kick the junk out of my head. Tomorrow looks to be an exciting day, with Jack's keynote releasing Ext 3.0, sessions on User Experience Design, Theming, and Performance Optimization. I'll be posting updates to Twitter and my Facebook profile throughout the day. If you're here, make sure to come up and say hi.

Ext.Direct: Details on Data Marshalling

$
0
0
One of the core focuses, in the development of Ext JS 3.0, is the marshalling of data services under a centralized location. The intent is to make for a more portable application, where you can have a single touch point for data I/O that could easily be switched from one platform to another. This is done through the new Ext.Direct package of classes, and many have been waiting on some detailed information on what it is and how to use it. This morning the Ext Blog got an update: Ext JS 3.0 - Remoting for Everyone. This explains Ext.Direct fairly well, even giving you a sample app to learn from, some sample code, links to some pre-constructed routers for several platforms, as well as a link to the Remoting Specification to write your own custom routers. Aaron Conran, Senior Software Architect and Ext Services Team Lead, wrote the ColdFusion Router. That's fitting, as Aaron's a long time ColdFusion guy, having contributed to the ColdBox project back in it's early days. I'm excited about what Ext.Direct can mean for Ext - ColdFusion based applications, and I'll be deep diving this integration soon. I'll be curious to see how I can integrate CFQueryReader into the mix. I have an update to that which I hope to get out in the next few days.

CFQueryReader v1.1

$
0
0
A while back, Justin Carter contacted me about some updates he was making to the ColdExt, a wrapper for the Ext JS library for ColdFusion. He had been looking at my CFQueryReader, as a reader for ColdFusion's JSON data return, and had noticed that there was no support for the 'root' attribute that's associated with most JSON readers in Ext. CFQueryReader is specifically designed for use with Query objects of ColdFusion 8's native JSON return type. When I first wrote CFQueryReader, I was replacing the CFJsonReader with something better suited to the array structure used in the ColdFusion JSON return of a Query Object, and really did a one-for-one port. So, I took a deeper look at the issue Justin wanted resolved. I did a deep comparison of Ext's ArrayReader and JsonReader source code, following everything that was being accomplished. What I found was how it used an internal accessor method to pull certain information on demand. I was able to refactor the reader to now support all of the base level meta attributes that are currently available to the ArrayReader: id, root, successProperty, and totalProperty. In the previous version of CFQueryReader, when defining your fieldsets you were also required to uppercase the entire value of the column names. This is no longer a requirement either, although casing is important in identifying your 'root' and 'totalProperty' attributes. The download below includes the reader, as well as some sample code showing how to implement it. I also setup these sample in a subdomain to show it working (requires Firefox with Firebug for full effect). There is a fair amount of comment documentation directly within the CFQueryReader.js file. A big shout out to Justin, Adam Bellas, and a few others, for helping me out with the testing.

Placement of the PagingToolbar on a Grid

$
0
0
This morning I found I was courtesy copied by Ray Camden, on a reply that he was making to a message he had received from his Blog Contact form from Mike Knox. Mike was trying to find out if it was possible to place the PagingToolbar, used in cfgrid, at the top of the grid rather than the bottom. Ray had told Mike that he had Googled it and not found on obvious solution, and that he was CCing me for my feedback. Like any padawan, it's pretty humbling for me to be asked advice from the Jedi Master. I've been taking Ray's advice on ColdFusion since the 4.x days, so I try to be pretty diligent when he includes me in helping others with their queries. I've always held that the use of the CF Ajax components are primarily for rapid application prototyping. They are fantastic for putting up some very basic functionality, but when you need more advanced configuration it is then time to dig in, and go straight to Ext JS itself. Mike's question is a prime example of this. We have nearly no control over a cfgrid's configuration prior to render, and the configuration options that we do have (through the cfgrid and cfgridcolumn attributes) barely scratch the surface to what one can do with an Ext Grid. The PagingToolbar is a class object of Ext and, as such, you should be able to add it to any toolbar of a grid: top, bottom, or both. I fired up Eclipse, booted up my CF and Apache, and pulled up the Ext examples from my local copy of the latest 3.0 download. All of the examples that you can see in the Samples & Demos section of the Ext site are given to you in the download of the library, so that you can run them locally and pick them apart. So, my quest was on. I went to the Paging Grid Example, and examined the source code of the paging.js file. I quickly found the configuration object for the paging toolbar: var pagingBar = new Ext.PagingToolbar({ pageSize: 25, store: store, displayInfo: true, displayMsg: 'Displaying topics {0} - {1} of {2}', emptyMsg: "No topics to display", items:['-', { pressed: true, enableToggle:true, text: 'Show Preview', cls: 'x-btn-text-icon details', toggleHandler: function(btn, pressed){ var view = grid.getView(); view.showPreview = pressed; view.refresh(); } }] }); The PagingToolbar instance is then applied to the Grid, placing the object in the 'bbar' (bottom bar) attribute: // paging bar on the bottom bbar: pagingBar After seeing this in the online demo, I went to my local (3.0) demo to see if I could change it. The Ext team rewrote the demo for the upcoming 3.0 release, placing the instance initialization directly in the attribute: // paging bar on the bottom bbar: new Ext.PagingToolbar({ pageSize: 25, store: store, displayInfo: true, displayMsg: 'Displaying topics {0} - {1} of {2}', emptyMsg: "No topics to display", items:['-', { pressed: true, enableToggle:true, text: 'Show Preview', cls: 'x-btn-text-icon details', toggleHandler: function(btn, pressed){ var view = grid.getView(); view.showPreview = pressed; view.refresh(); } }] }) So, I changed 'bbar' to 'tbar' (top bar) and reloaded the page. Success! The PagingToolbar was now in the top toolbar of the Grid, and fully functional. After reviewing all of this, I decided to go a step further. Could you have two separate PagingToolbar configs on the grid? One at the top and one at the bottom? So, I tried this: // paging bar on the bottom bbar: new Ext.PagingToolbar({ pageSize: 25, store: store, displayInfo: true, displayMsg: 'Displaying topics {0} - {1} of {2}', emptyMsg: "No topics to display", items:['-', { pressed: true, enableToggle:true, text: 'Show Preview', cls: 'x-btn-text-icon details', toggleHandler: function(btn, pressed){ var view = grid.getView(); view.showPreview = pressed; view.refresh(); } }] }), // paging bar on the top tbar: new Ext.PagingToolbar({ pageSize: 25, store: store, displayInfo: true, displayMsg: 'Displaying topics {0} - {1} of {2}', emptyMsg: "No topics to display", items:['-', { pressed: true, enableToggle:true, text: 'Show Preview', cls: 'x-btn-text-icon details', toggleHandler: function(btn, pressed){ var view = grid.getView(); view.showPreview = pressed; view.refresh(); } }] }) That's part of what I love about development, I get to play, experiment, have some (geek) fun. After refreshing the page, I now had two toolbars, at both the top and bottom of the page. Both worked perfectly, and stayed in sync during paging. That's what I love about the Jack Slocum and the Ext Team, they think about things like having more than one paging bar and how they would need to stay in sync, and they've already written it in to the library. And so, on rare occasion, the student has the opportunity to become the master, though I'm sure there's still plenty more I can learn from Master Camden;)

CFQueryReader v1.2 - Critical Update Supporting ExtJS 3.x

$
0
0
I have updated CFQueryReader, addressing issues that had arisen with new builds of ExtJs 3.x. This new build should cover sporadic issues with loading a new Ext.data.Store. There is also a simple example of using Aaron Conran's DirectCFM Ext.Direct ColdFusion API stack. The CFQueryReader Example Site has been updated as well. You can update CFQueryReader from RIAForge.

Scope Usage and Application Scaling

$
0
0
Mike Brunt has posted an excellent article called Good Practices For Scaling ColdFusion Applications, in which he speaks about the importance of memory management within ColdFusion applications, and calls out certain avenues of scope usage that every CF developer should pay attention too. Great post Mike! Another 'scope' issue that I've often seen (and abused myself) is the misuse of the VARIABLES scope. Back in the early days of CF, every example you saw showed an unscoped variable, placing it into the VARIABLES scope by default. This was fine, back then, as your view layers primarily consisted of Custom Tags. Use of the VARIABLES scope, within a custom tag, was permissable as those variables were then only available within that tag (or within a nested tag, if the nested tag used the CALLER scope). Once execution of the tag was completed, the memory space of those variables was cleared. But, since custom tags were made from .cfm templates, there is no constraint within CFML from placing VARIABLES scoped variables within any .cfm template. This, in itself, is bad, as the VARIABLES scope (in the case of a base template, not a custom tag) is not properly cleared from memory space. What I find people doing (and I've done it myself) is using the VARIABLES scope in place of the REQUEST scope. Memory allocated to REQUEST variables is properly recovered at the end of a request. Although variables in the VARIABLES scope are no longer available (except within a persistent CFC), their memory isn't properly released at the end of request execution. (For more information on this, see Jason Sheedy's post on the ColdFusion Memory Leak, and the accompanying comment thread and other referenced posts.) A technique that some used, to get around this issue, was to have a StructClear(VARIABLES) statement as the last line of their onRequestEnd.cfm. This would explicitly clear out the VARIABLES scope at the end of a request. But, with the advent of Application.cfc, this no longer became an option (if you use Application.cfc.) If you tried to use that statement within the onRequestEnd() method of Application.cfc, you would only be clearing the VARIABLES scope of the CFC itself, and not the request. That's actually a good pointer at the true underlying issue: proper scope usage. Use of the VARIABLES scope within a CFC makes variables within that scope only available directly by all methods of that CFC. Use of the VARIABLES scope within a custom tag makes variables within that scope only available within that tag (or a nested tag using the CALLER scope to access them.) Within a custom tag, you can not access variables of the calling template's VARIABLES scope, unless you use the CALLER scope to do so (which should only be in the case of a nested custom tag). You can, however, access REQUEST variables through out the request, from within a custom tag, an include file, or even within a CFC (though I wouldn't suggest doing that one.) By confining the usage of the VARIABLES scope to within custom tags and CFC's, and properly setting request level variables within the REQUEST scope, you could better manage your memory usage and application performance. I've personally seen major differences in application performance, both through Mike's advice on persistent scope usage, as well as what I've outlined above. Unlike Jason Sheedy though, I'm not very familiar with Java profiling tools, so I'll have to leave it up to someone else to test all of this for the scientific proof. I only know that it appears my applications are running better as I migrate them to this paradigm. What are your thoughts? *** Post Revision 080609: 2230 hrs *** More revision to my comments than the post itself, but Ray, the ColdFusion Jedi himself, corrected me. According to Ray, the VARIABLES scope wasn't added until CFMX, so my supposition on the 'intention' of the VARIABLES scope was incorrect. You really have to read the comment thread to see the fun we're having;) Hopefully we'll find an answer. Cutter

Request vs Variables - Which is right?

$
0
0
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)





Latest Images