« The Dopefly Tech Blog Main page
I don’t know how Pete Freitag dug up the video from my short lightning talk on ColdFusion’s client variables (and why you shouldn’t use them), but I’m glad he did! Pete put it into his newsletter (that you can subscribe to at foundeo.com) which I think is really cool. Check out this video - it starts at about 1:30 - Client Variables Lightning Talk.
(Discuss with Disqus!)Many of you know me and where I work. If not, let's just say it's a big place with lots of smart people who all have their own motivations that generally align with making money. Over the past couple decades, we've had an increasing number of ColdFusion applications, mostly on the company intranet. At this point we have literally thousands of CF sites and apps, developed by hundreds of skilled and unskilled ColdFusion developers. We also have a heavy investment into server architecture to support this. It's not been cheap or easy to get here.
Why, then, did we make the decision to leave ColdFusion?
Over the past few years, our Enterprise Architecture department has been trying to reduce the amount of variation in applications around the company. It makes sense because having a more homogenous server and application architecture can reduce costs. So what did they pick instead? The new application infrastructure is going to be nothing but Java, especialy with Spring MVC, and ASP.NET MVC. That's it. Nothing else.
We know from lots of experience that neither Java nor ASP.NET is actually a cheaper solution because of the cost of IDE software and other various servers and components to match the functionality in ColdFusion. Also, a Java developer has a more demanding salary than someone who does a little more than HTML, or an analyst who dabbles in dynamic web programming. Long story short: We're not doing it to save money.
Is it because ColdFusion is last decade's technology? Well, what does ColdFusion do? It puts web sites on our intranet while connecting to every type of other system we may have running. Okay, it's not tablet apps, but it can let you create mobile web apps. It stands as a sturdy back-end to JavaScript applications. This is not old technology, not by a long shot.
Are we dumping ColdFusion because of a rapidly shrinking talent pool? Maybe. It's hard to say because we haven't been hiring a lot of people over the past few years. However, if you've ever seen ColdFusion, you know it's essentially HTML-plus. CF's unbelievably low barrier to entry means anyone with HTML skills and 15 minutes of playing around can write CFML on their resume. Complex CF applications are something else, but are generally along the lines of any MVC application on another platform. Also, as I said, we already have hundreds of ColdFusion-literate people - we're not short for talent.
No, instead of all of this, we are moving away from ColdFusion because of Gartner's IT Market Clock for Programming Languages. I've read it - Gartner does a very strong analysis of the market as a whole from what information they can learn on the public internet. They check the job sites and question boards like StackOverflow, and they determined that ColdFusion is on the brink of obsolescence. In our proactivity, we are jumping off before it gets ugly.
So why are we moving away from ColdFusion? In a word: Gartner.
In my rush to make unit tests on my work primary development application, I've been putting unit test files all over the place. I don't think this is necessarily bad, as I've been telling myself it's better to have unit tests in the first place. Certainly unorganized unit tests is better than no unit tests whatsoever. I have a somewhat organized unit test runner, and my tests all fall into a larger test suite that provides the illusion of organization, yet still the files themselves are not organized.
So what is the best method? Unit test files in the same package (CF term for a folder) as the files they are testing? Tests in a central location? Mixed in with the model? Outside of the application you publish?
My current mode of thinking is to pull them out into a separate project, sort of a "project-contrib" project, for things like documentation and unit tests that I need, but don't want to deliver to the production web server. What do you think? What's worked for you?
TIA.
Ten years ago today, ColdFusion 6 was released.
Affectionately named CFMX, this sixth major release was a full rewrite out of a C++ core and into a Java EE core. ColdFusion would now be deployed on JRun for the next decade, the formerly current J2EE server, also from Allaire. Other major features were CFCs (ColdFusion Components), enabling an object-oriented programming style that has largely taken over in the CFML-writing community, also web services, native XML abilities, a new charting engine to replace the outdated C-based graphing engine, a new security system, and full support for internationalization and localization. This was a giant fundamental shift for the hundreds of thousands of ColdFusion applications in the wild, and was largely backward compatible.
Cheers to you, Macromedia employees, who pulled off an incredible technological jump, one decade ago, today. Thanks for indirectly employing me, all these years.
There has been a lot of confusion about closures in ColdFusion 10, and I don't think anyone has done a good enough job explaining it. I'm going to try to make it easy.
First, understand that what we call the closures feature is actually a handful of related ideas: anonymous functions, named function expressions, functions as first-class citizens, nested functions, and yes, true closures.
An anonymous function is simply a function without a name. You define it inline, usually as an argument to a function call or as a function's return value. Eventually it may have a name, but at the time and scope of its creation it does not.
A named function expression is another way to define a function. Instead of the classic function operator syntax, function name() {}, you define it a lot like any other variable. Name equals value. var name = function() {};.
Functions as first-class citizens finally reinforces something we have had unofficially since ColdFusion 6.1, passing a function as an argument. The difference now is there is a function data type. This helps us formalize a functional programming paradigm in a previously object-oriented CFML.
Having nested functions means that you can define a function within another. At its most basic, you can categorize you methods, hiding them in another function, and make little helpers that you only call from that defining parent function. You can define them in the classic function operator syntax function name() {} or in the expressed var name = function() {};.
Here is where it gets fun.
That inner function has access to the var scope of the function it was defined from. This is what a closure is. It knows about its origin and it doesn't forget. It will always be tied to that same parent var scope.
Combining those ideas, you can define a function within another and pass it out (with or without assigning a variable name to it), then that outbound function can use its closure abilities to reference data in the method it came from. This is where much of the power of Javascript comes from, and provides a good start to doing functional programming.
The similarities between what CFML will do in CF10 and what Javascript does are incredible. I love the direction we have seen so far, and I am excited for the future of ColdFusion!
I have been working on a project for a while now. Really, for about 6 years, but only in the past month did I get everything written down. I call it The Final Nail for ColdFusion Client Variables. It's an eight page (printed) look at ColdFusion's client variables scope, and all the problems that come with it.
If you are looking for a reason to go through your ColdFusion app and replace you client vars, print off a copy and take it to your manager.
If you use client variables and think everything is fine, I suggest you read it and find out exactly what you have gotten yourself into.
If you are in love with client variables, well, I'm so sorry. I'd hoped we could be friends. I really am a nice guy, but we have to draw the line somewhere.
I had a ton of help, so thanks to everyone who pitched in (whether you know it or not)!
Last, this is the standing comments post for the article, so if you want to talk about it, this is the place. You can also get me on twitter, @nathanstrutz if you have any quick comments.
That's all; enjoy The Final Nail for ColdFusion Client Variables!
Oh no, the last day!
Early on, I went to What is Function Programming with Sean Corfield
Slides
I get it, finally. Not that I hadn’t seen FP before, not that I hadn’t had it explained before, not that I am going to start writing clojure today, but now, at least, I get it. Here’s the short answer. The strength in functional programming comes down to map and reduce, and to having very limited side effects except for transforming the data - this explains why it’s great for testing, for thread safety and thus parallelization. Sean is always great to listen to, and it’s usually about something cutting-edge, pushing us over the cliff so we can try our wings. As a bonus, we also had an interesting discussion about closures versus anonymous functions (hint: it’s about context) that we got to continue at lunch.
Next I went to Relax with CouchDB by Mark Drew
Slides (pdf)
Mark went briefly over NoSQL databases, which made me wish I saw Peter Bell’s NoSQL talk on Thursday. I picked up everything I could during his brief NoSQL discussion, I especially liked the slide on the CAP Theorum, with what category databases fall into (you can see it here). Mark is funny on stage. He keeps the crowd awake by throwing things at them. Candy, USB drives, toys, etc. It’s entertaining (and dangerous). CouchDB looks like an awesome product, and Mark made a really nice case for it. It’s essentially a document database with a REST interface. He showed it returning a lot of JSON, but I’m sure it can do more.
Before lunch I sat in on Just Mock It with Louis Majano
Slides (pdf)
I saw this at the MAX unconference tent, but a couple things have changed - I am developing for CF9 now instead of CF6, so a mocking framework is feasible, and MockBox version 1.3 was released, so I was hoping to see something new. I didn’t see anything new, so that was a bummer. What I got instead was a refresher course on MockBox and some tips on unit testing, not a loss at all. Mocking is an important topic when you talk about unit testing. Some tips I got were to make a 1:1 relationship from components to test components, remember to test private methods, with mocking you can test what happens when another component throws an error, and a good source for unit testing examples is ColdBox’s test suite. Final note, it’s easy to get lost in Louis’ fantastic accent!
A scene from Lunch
After lunch was Time Management for Developers by David Shepherd
No slides
David gave the case for using Mylyn in Eclipse, and showed how it works. Unfortunately I was underwhelmed by the presentation, I don’t know what it was about it, maybe just because he was sitting for it, maybe because it was right after lunch. Even still, Mylyn gets a win. It lets you keep context while you switch between tasks, it lets you share your context with other developers, and it integrates your tasks with bug and task tracking systems. Cool product. I’ve already started trying it out!
Finally, the last session, I went to AngularJS with Elliott Sprehn
No slides
Elliott was the one who talked me into writing my session notes on this blog. I have to say I was overwhelmed by Angular. I told him afterward that for a bit, it felt like he was just telling us everything we wanted to hear, it was too good to be true: How would you like a javascript framework that works with jQuery, gives you includes and templating, dynamic variables, 2-way data binding, magical mustache expressions, unicorns and rainbows, total extensibility, ORM over REST, MVC for JS, mocking and unit testing, free beverages for life and a friendly DSL for writing tests, plus it’s smaller than jQuery and written by Google. Yeah, that’s AngularJS. Basically, I think he was trying to blow us away in order to get us to try it out. It worked. I am now getting familiar with the double-magical-mustache syntax. I just need a project to put it in. You should look into it yourself.
That’s a wrap.
To summarize CF.Objective() 2011 for me, I will say that I met a ton of amazing people, talked about a lot of programming, learned a huge amount of things, shared ideas with the best minds in ColdFusion and was blown away with the things some people are doing with this technology. CF.Objective() truly made me a better developer. My take on the conference is that they billed themselves as the conference for enterprise ColdFusion development, and they delivered.
Thanks to the organizers, the speakers, the other attendees and the sponsors! You are all doing great stuff. Believe it!
(Discuss with Disqus!)Second day!
First up, I went to Setting up a Solid Local Dev Environment with Kurt Wiersma
Old slides
Kurt told me it was going to be stuff I already knew, but I like to assure myself that I'm doing things right, or if not, that I at least know why I am doing it wrong. He was right, I didn't learn a lot, but it made me think about the way I do it versus his. He recommends the Apache/CF Multi-server stack with a shared database. I have been doing stand-alone CF with the built-in server, which has been great for my current projects. Also, he mentioned DDLUtils, which I need to play with. In the end, it was a well thought out session, and Kurt did it like a pro.
Second session, No-Nonsense REST & Taffy with Adam Tuttle
Slides
The first of two consecutive REST sessions, Adam talked about the tangible use of RESTful services in ColdFusion. The 5-minute intro to REST was just what we needed to get going, then he showed what it takes to do it in CF - y u c k. Hundreds of lines of code - we need a framework! Intro Taffy, a simple conventions-based RESTful framework for CF kind of like FW/1 meets jQuery, then mashed into REST. The killer feature of Taffy I think is the dashboard, which lets you call your REST services from an admin-like interface. Adam was funny and his software was keen.
Here is Adam talking about boring programmer stuff
Last before lunch, Everything you wanted to know about REST with Simon Free
No slides
Simon Free's REST talk right after Adam's was very helpful. Simon approached REST with the sort of philosophical hippie free love type of approach that REST was based on, which I think is comical because Simon is really just a cool, smart guy, not the hippie type. It was great to finally have someone tell me exactly what REST is and everything it stands for and how it was really meant to be used, plus how where and why to break the rules. I had a lot of takeaway points, so this one was a win for me.
After lunch, I gave my presentation, Holistic Program Quality and Technical Debt. I think it went pretty well. I could criticize myself all day on my performance, but instead, I will say I had a good interactive audience considering it was right after lunch, there were maybe around 40 people (?), I got a few laughs, we had some discussion at the end on code reviews, I think I hurt some people's feelings in a thought-provoking kind of way, which is good, then I had some requests to re-use my slides for themselves, plus one person called me "smart guy." Still I was kind of unsure until Sean told me that he liked it (but in person, not just on his site). Whew, that did a lot for my nerves, thanks! I felt better. A few kind words go a long way.
Slides
In the last session of the day, I went to A Git's guide to Gitting along with Tim Cunningham
Slides
Tim did something unique, he pre-recorded his screen as he used Git and while it was playing, he talked over it. It ended up being a little bit awkward because he hit the ffwd button a few times on accident, and sometimes couldn't pause it fast enough. Tim does great in front of a crowd and is fun to listen to, so it was kind of a bummer that the recorded part was only so-so. That said, I learned a great deal about how Git works, it's impressive and I am going to start using it because of this session. Mission accomplished, Tim.
CF.Objective() was well attended. Here is another shot from the keynote. My day 2 photos were lacking, so I'm dropping it here :-)
Well it's been a week since CF.Objective() ended, I thought I would share my notes on the various sessions I attended.
There was the keynote.
I don't really have any notes on it except it was good and I wish it could have gone longer.
First session, Progressive Enhancement with Barney Boisvert
Slides
Somehow I was expecting something different. Stick with me here. The way Barney presented progressive enhancement versus graceful degradation was surprising. It's hard to explain, but he had the whole room on the edge of their seats with an escalator metaphor. His delivery was great and the content was perfect for the current state of web development (HTMl5, CSS3, javascript frameworks). The overall idea is that you should make your web applications work on the most minimal browsers, then progressively enhance the experience for better browsers. Hoping your application degrades gracefully isn't good enough. Great session. Really made me think.
Next, ORM Zen with Marc Esher
Slides
Marc has a really good presence on stage, and the way he presents and speaks somehow creates interest in every word. What came out this time was a very practical, very real-life discussion on making CF's Hibernate-based ORM work. There are a lot of finer points that I didn't know about, having only done one small ORM project in the past, so it was really helpful. Some of the takeaways I had were to turn off ORM sessions, always use transaction{}, always set the inverse property on a one-to-many join. I am going to hang on to his slide deck, as it's full of good insight.
After lunch, I went to ColdSpring 2.1 (alpha 1) - What's New and Improved with Mark Mandel
No slides
I gathered from the audience that this is the annual ColdSpring 2.0 talk. It's not vaporware, in case you were wondering, nobody said it was (certainly not me). The alpha release is coming as soon as Mark writes more documentation. I understand that, especially after seeing it in action, CS2.0 does a lot of new things. Mark's always fun to listen to, and he's crazy smart. Some of the new features include easier XML configuration, a pluggable architecture with xml namespaces, including one that will make AOP much easier to do. Annotation-based injection could make a debut for CS2.1. Thanks, Mark, we're all looking forward to it!
Here is Mark Mandel and Louis Majano, the authors of the top two dependency injection frameworks in ColdFusion, discussing how to borrow features from the other.
The final one of Friday was on Continuous Integration with Marc Esher again
Slides
Again, Marc is great to watch, always has well polished sessions. I don't know that I picked up a lot from this talk, but the slides were good. I don't do continuous integration, it's kind of tough in my corporate environment, but Marc is the second speaker I have heard mention how amazingly good Jenkins (formerly Hudson) is. Above that, I do Ant ("You can't avoid Ant any longer"), and I use MXUnit for unit tests ("No project ever started with 500 tests, they all start at zero, so it's always a good time to start"). The way Marc related Ant to CFML was brilliant. cfparam = property, cffunction = target, cfinclude = import & taskdef. Check his slides for the rest. It was a good talk, well done.
Here is Marc on stage.
Later that night were the lightning talks. I was up third, and I think only Ray was as nervous as I was, which made me feel ok for being nervous. The talks were surprisingly varied. The baseball card market, the philadelphia library, apps for coldfusion, brewing beer, love, CF server troubleshooting, motorcycles and much more. I think mine about client variables went pretty good, I had some good reactions from the crowd, and I'll get that content up here pretty soon.
That's the end of the first day. I'll have the next day up soon.
Hey, you know how you've been meaning to learn how to program a little something here and there in ColdFusion, like this is an item on a to-do list that you just never quite check off? Well get your marker out - you can learn CFML in a day, and it won't cost you a thing.
On Saturday, November 13th, we're putting on a CF DevCamp. It's a full day, bring-your-own-laptop training session. We've got a big speaker (Terrence Ryan), corporate sponsorship (Adobe), food and drinks (SanTan Brewing Co), and plenty of stuff to give away (shirts, books, stickers and flash drives with all the software you need). Best of all, the day's events are free.
You can sign up for the Phoenix CF DevCamp now, or read more about the Phoenix CF DevCamp on our web site. This is a really, really good deal, think about it!
Just a quick note to say that I did hear, from the mouths of Adobe employees over this past week at MAX, that ColdFusion 10 is in development, and I saw, with my own eyes, ColdFusion Builder 2.0 running in a preview capacity.
For ColdFusion 10, they didn't announce anything at all about it - absolutely nothing, which is a little disappointing. All I got was a sentence fragment that confirmed that it did exist. Still, I can't wait until details start leaking out.
CF Builder looked really good. Raymond Camden already wrote down pretty much everything he saw at the preview. My quick take on it is that CF Builder 1.0 was trying to catch up with CFEclipse in a lot of ways, then surpass it in just couple, but 2.0 is improving on and surpassing all previous efforts pretty much everywhere. If you weren't impressed the first time around, stay tuned for a real, competitive IDE.
It's no doubt that code reuse is an important part of programming. Here's a list of ways you can do it while you're programming in ColdFusion.
<cfinclude template="file.cfm">
#variable#. Unlike classic ASP, the file is included only when the tag executes.include "file.cfm"
cfinclude tag and behaves similarly.<cf_file attribute1="value1">
<cfmodule [name= or template=] >
<cfimport namespace="imported"> ... <imported:file />
cfimport tag must be applied on every template you wish to use the namespaced file set in. Imported files behave like custom tags in that they use attributes and can have a closing tag, but it can also be used for JSP tagsets.<cffunction name="reusable"></cffunction>
function reusable() {}
cffunction. Since CF9, it can use extra syntax to give more metadata and control like the tag-based version has.<cfcomponent> ... </cfcomponent>
component { ... }
cfscript tags.<cfobject >
createObject("component", "myComponent")
new myComponent()
cfobject and traditionally the easiest way to create an instance of any CFC.<cfinvoke>
Yesterday I talked about how we have too many choices when people get started using ColdFusion. There were some really good comments, and the consensus was that more is always better. I agree with that, for the most part. I promised I would share my idea for a solution.
My opinion is that you have to try them all. Yeah that sucks but there's a lot of truth to it. You just can't get a feeling for a tool until you try to make something with it.
For an IDE, spend a week with it. For any type of framework, make a little sample app - I like to make a generic list-add-delete program, which gives me enough of a feel for where things go and how you interact with them. Experimentation is essential.
That's my opinion, but the solution is not good enough. What can we do so people don't have to try everything, every time?
I hate to point out problems without offering the solution, but worse yet, I hate offering a solution without offering to do any work. So here I am, a hater. If someone starts it, I would pitch in.
We need a wiki that compares and contrasts all of our options. They need to be categorized (like I did above), give a short description, explain the popularity (or lack thereof), show some screenshots or code, talk about how they work compared to other options, discuss downsides and difficulties that people have (especially problems that new initiates have, all in order to overcome them), and finally, provide links to the most popular resources.
The best we have as of today is
Sean Corfield's framework comparison discussions. They're outdated now, and it was a valiant effort, but not good enough.
And with that, I'm going to end it abruptly, again.
Too many choices is both a way to fail and a way to succeed. The choices make it undoubtedly more difficult to choose your development path. Let's talk about some of these choices.
IDEs: CFEclipse or ColdFusion Builder for Eclipse lovers. Dreamweaver and HomeSite for the traditional people. And then there is the plethora of other multi-purpose-but-supports-CF notepad replacements, including but not limited to: TextMate, Notepad++ and jEdit.
Front Controller Frameworks. Fusebox, Mach-II, Model-Glue, ColdBox, OnTap and CFWheels, not to mention the newer minimal frameworks, FB3Lite, LiteFront and FW/1.
ORM tools, from Transfer to Reactor, CFWheels' built-in ORM and Hibernate via CF9's ORM.
Bean Factory / Dependency Injection Frameworks, including ColdSpring, ColdSpring Lite and LightWire.
Servers: Adobe ColdFusion 8 or 9, in demo, developer, professional or enterprise flavors. BlueDragon JX, Java or .NET in enterprise or standard and Open BlueDragon, and Railo regular, express with Jetty, express with Resin or custom.
And that's leaving out most of the alternatives that are pure crap, as well as not even thinking about entire categories of applications like CMS', Blogs, Wikis, and so on.
There are a lot of things a new developer has to weed through. How do you choose?
This is sort of an abrupt ending, so I'll try to hit this again tomorrow.
I always hated them for this one reason. How do you explain this URL:www.example.com/index.cfm?fuseaction=main.default
What I dislike about that is...
My last blog entry was about how to create the easiest ever MVC application, but looking at it, you have to see where you'll just start repeating things all over the place. I mean, look at this code:
/app/controller/main.cfm
<cfinclude template="../model/main.cfm" />
<cfinclude template="../view/main.cfm" />
<cfparam name="action" default="main" />
<cftry>
<cfinclude template="controller/#action#.cfm"/>
<cfcatch />
</cftry>
<cftry>
<cfinclude template="model/#action#.cfm"/>
<cfcatch />
</cftry>
<cftry>
<cfinclude template="view/#action#.cfm"/>
<cfcatch />
</cftry>
Slowing down and backing up, this is a very quick introduction to making an MVC application in ColdFusion.
First, make yourself an appropriate directory structure. Follow along here, it's really simple.
There are a hundred a thousand infinite different ways to go from here. Let's try the most basic way I can think of. Your browser should always hit the controller no matter what, so let's put in an index.cfm to redirect /app/ visitors to a default controller, /app/controller/main.cfm.
/app/index.cfm
<cflocation url="controller/main.cfm" />
<cfinclude template="../model/main.cfm" />
<cfinclude template="../view/main.cfm" />
<cfset name = "Nathan" />
<cfoutput>Hello, #name#!</cfoutput>
C# was the first mainstream programming language, to my knowledge, that had full language support for properties, phasing out getters and setters (accessors and mutators). The idea is simple. Here is a property:
public String Name;
Name, such as calculate the value on the fly, or invalidate a cache when the value changes like I do in Pagination.cfc, you have to graduate this into a getter and setter. In C#, you just have to change the property, keeping your object's interface safe:private String _Name;
public String Name {
get {
// some code
return _Name;
}
set {
// some code
_Name = value;
}
}
Since Mark Mandel gave his transfer presentation to the AZCFUG last June, I've been contemplating the different ways there are to work with and customize generated code, and especially re-generated code. Here are some patterns I have recognized. Please read and add your own in the comments.
Generic Scaffolding
Something I've said ColdFusion has needed for years, and we're still not there, standard scaffolding creates the model, view and controller on a single database table (not usually much more complicated than that). From there, you have to edit the HTML to make it match your UI, and edit everything else to do what you need it to do. It's rarely correct out of the box. When your database structure changes, you either have to regenerate and reapply your changes, or apply the DB changes to all of your layers by hand.
Styled Scaffolding
If your UI is clean, and the scaffolded UI code (the HTML) is as well, leave the output as is and just style it with CSS. Wrap your own layout around it and you're set. This only accounts for basic changes that you would make.
Transformed Scaffolding
To account for bigger changes, like changing form field types or turning a form into a wizard, you could try running a transformation on the scaffolded output. This works by making a tool that will change the original structure on command, for example string operations on code. It's doable, and I've done it. It works, in a pinch, but it tends to be more work than it is worth. If you end up physically injecting code into an object, there are better ways to go.
Extended Injected Stubs
Extend the generated code with your own objects (or inline includes for HTML). Replace calls to the generated code with calls to your code. It's kind of a make-or-fake-your-own-stub strategy.
Pre-generated Stubs
The Reactor ORM has a neat trick. Reactor generates stub classes that extended the framework's real generated classes. These empty stubs are placed in your playground to put in any code you want, while the tabe definition heavy lifting classes are saved inside Reactor's core file structure. Reactor can then manage the ORM while your stub files are safe. This strategy can work for you, too, except for the two big downsides that ultimately killed* Reactor: folders with potentially huge numbers of generated files and the unweildy nested object structure. CF 6 and 7 especially have trouble keeping performance with the inheritance tree, which, from memory, looks something like:
reactorObject* No, it's not dead, but had a little bad press and it was hurt bad enough to end up on the outside.
reactor.DataObject
reactor.DAO
reactor.myTableDAO
myTableDAO
myTableDAO_MSSQL
There's always all this talk about how ColdFusion costs so much more than the competition. This has of course been debated and debunked, but still, the truth is, ColdFusion still does cost, whether we're talking about the US$1300 standard version or the US$7500 enterprise version, that's real money that you don't always have to pay. I've got two methods that will give it to you for free, and three methods that will show you how to get it for a severe discount.
Free #1- Visit Adobe.com, download a trial version, install it. When it asks for a serial number, tell it to install the developer version. This is literally everything that the $7500 enterprise version has, yours free forever, no license problems, no hidden fees. The only downside is it's limited to IP addresses - the local computer (for development) and 2 or 3 others for development and testing.
Free #2- Hang out at your local Adobe sponsored user group (CFUGs especially). Twice a year, they give out a software package from Adobe, anything they have for up to around US$2000. You can get your free copy of ColdFusion just by being lucky or entering whatever contests they have. This is actually more viable than it may seem. A few years ago, I won this. Months later, I brought my dad to the group and he won. Oh, and since you'll be there, take time to meet interesting people and learn some CFML.
Cheap #1- Maybe you knew this and maybe you didn't, but you really don't have to buy ColdFusion to run a web site with it. $20 or so a month will give you a great generic hosting account. Develop CF locally for free, deploy remotely for cheap, it's an easy win. Also, these hosted servers usually score the expensive enterprise version, so you can even use those cool advanced features.
Cheap #2- If you do go and buy your own copy of ColdFusion Server, you may not know about the changes to the EULA, or License Agreement, since ColdFusion 9. If you buy just one copy of the server software, that grants you the ability to use that license to install on development, testing and staging servers. That's like 4-for-1, a savings of US$3900!
Cheap #3- If you go all out and buy that US$7500 enterprise license, and there are some good reasons to do that, consider deploying to a cloud environment like Amazon EC2 or the like, because you can deploy your enterprise CF copy on 10 cloud servers. That's a savings of US$67,500! It sure does give you more incentive to try out load balancing and the new multi-server configuration tools that ship with CF9.
With CF being OO enough, beans can have a super-type, a common base that all beans share, like genetics for business objects. It's easy to make one.
<cfcomponent extends="superbean">But what do we put in there?
obj.Name("Nathan").name(); which would return Nathan - somewhat of a jQuery style trick. Another cool thing is that if you wanted to create your own getter or setter for a property, the _generic methods will search for your function and call that instead.(in component user, extends BasicGenericBean)
function getName(){return "Bob"}
(Outside, calling methods on the object)
user.setName("Nathan");
user.getName(); // returns Bob
<cfcomponent extends="GenericBean">
<cfproperty name="Name" type="string" />
</cfcomponent>
user.setName("Nathan");
user.setNumberOfGoats(16); // throws error: NumberOfGoats does not exist in User.
What happened to the early days of using Java as the model for a ColdFusion-based MVC application? We used to talk all about CF w/Java but I don't hear it anymore. At best, it's rare. I like to keep my ear to the ground in the CF world, and this one has quietly slipped off the radar.
I guess there are only a few likely demises:
createObject("component","com.myCFC") will make ColdFusion to check a variety of locations for that object. First one it finds, wins. What if you could just create a .java or .class file and call it in the exact way you call a cfc using CF's smart path finding senses. I'm honestly surprised that we can't do this yet. For me, personally, this would quickly and easily bridge MOST of the gap.myService.getMyData(). The service calls a cfc to get the data, then populates a bean or returns a query or whatever. Problem is, Java can't call methods on a CFC! No, I'm not kidding. Try it. Oh, and yes, I know about the cfc gateway, an asynchronous method for Java to call CF - and no, that doesn't count. Yes it's great and powerful, but that's just not it.cfquery! I think the real heros in this space seem to be Barney Boisvert, who is always blogging about integration with hibernate and groovy, and Mark Mandel with his JavaLoader project.For a while now, the CF community has been stumbling around the concept of calling a dynamic function. Well, as it turns out, ColdFusion is more functional that it may seem on the surface. Let’s have some fun with what, at first, seems like a difficult problem.
Let’s say we have a method that receives the name of another method as an argument: myStaticFunction("myDynamicFunction"). Now what? First, here’s the methods (I haven’t checked any of this, so let’s call it pseudo-code.
function myDynamicFunction(){return true;}
function myStaticFunction(methodName) {
methodName(); // fails for calling a string like a function
variables[methodName](); // fails for a syntax error - []() = bad cfml!
// umm, now what?
}
So here we are in the same old spot. First, the old school method, the one easily turned to in time of need, the cfinvoke tag. Personally, I dislike the cfinvoke tag. It seems to take me out of my flow. It ruins my mojo. It’s like longhand syntax for CF - it’s somewhat of an oxymoron. Nevertheless, here’s what you would do:
<!--- First, note that we have to rewrite it in tags. Not awful, but I dislike the switch. --->
<cffunction name="myStaticFunction">
<cfargument name="methodName" />
<cfset var methodResult = "" />
<cfinvoke method="#methodName#" returnvariable="methodResult" />
<cfreturn methodResult />
</cffunction>
This works, but there’s got to be a better way! There has to be a less cheap way, something without all the #'s and stuff. And there is:
// back to cfscript, yay!
function myStaticFunction(methodName) {
var method = variables[methodName];
return method();
}
That’s much more like it! Of course this assumes we’re in a cfc or something, where the method is in the variables scope. Now, what other magical things can we do?
Well, I wasn’t going to share this one until the next entry, but since you’re talking me into it, here it is with onMissingMethod, dynamically calling a method with dynamic arguments. This onMissingMethod attempts to call a getter when you just call the property - in other words, user.name() will be automatically translated into user.getName(), to give you a nice jQuery type of syntax:
function onMissingMethod(missingMethodName, missingMethodArguments) {
var f = 0;
if (structKeyExists(variables, "get" & arguments.missingMethodName)) {
f = variables["get" & arguments.missingMethodName];
f(argumentCollection=arguments.missingMethodArguments);
} else {
// choke!
}
}
One of my favorite little tricks to play with CF, and with other dynamic languages like it, is aliasing function names.
Let’s say you have a component, User, and a method, getIsUserNameValid(). It’s a “getter” in order to satisfy some other kind of style requirement, but writing it out is verbose and feels wrong:
if (user.getIsUserNameValid()) {...}
You have to leave it as is so you don’t break any existing method calls, and to keep the basic style guidelines, but what if you could cheat a little? Consider this:
<cfset variables.isNameValid = variables.getIsUserNameValid />
<cfset this.isNameValid = this.getIsUserNameValid />
In ColdFusion, this creates an alias in the private "variables" scope as well as the public "this" scope to the old method. Now you can change your call to:
if (user.isNameValid()) {...}
We've heard it, we may have seen it in action. If you have ever asked yourself "why," this is for you.
(BTW, I'm just going to call it a "facade" because "façade" is too difficult for my keyboard to produce)
The Pattern
A facade is a fake front, like a mask. A session facade hides away the "complexity" of using a session.
The session facade is the point-of-contact for your session variables. Using one, we no longer have a session scope that you can talk to, now we talk to the facade. The facade offers basic bean methods with generic names - get(), set() and delete(), or a variation on the theme.
Dave Ross has pretty much the definitive ColdFusion Session Facade article (2 pages worth and sample code) - how to use it and all. I'm just considering the usefulness of it.
That sucks
Instead of #session.username#, now we can just type #application.objectFactory.getBean('sessionFacade').getData('username')# and the session facade will handle the dirty work of typing the scope name "session" for us. Finally, more typing!
So now that we're typing more, we also have to learn a new API for managing the session scope. What if we use get, put and delete methods and our friend Bob Bobbery uses get, set, remove, clear, search, etc, etc? More to learn equals more complexity.
And what problem exactly did this fix? We had a session scope before, and we technically still have it. Nothing forces the bad coders on our eam to use it. Nothing really changes, assuming the facade just gets and sets variables from the session scope. It just added another CFC to manage and a bunch of extra code.
The final problem is that the session facade doesn't do anything to manage the session, to organize it, report on it, fix problems that could occur or reduce complexity. It's typically just a dumb bean with variables.* replaced with session.*. It's useless.
Oh, that might be cool
We programmers are managing change. That's one of the things that we do, and hopefully, we will do it well. What if the session scope goes away... no not likely, but with a session facade, we have the mechanism to manage every variable in and out of the session scope. We could reroute it to a database.
The session scope could disappear due to an administrative switch. On a hosted server, we may have no choice. The session facade could then be changed to get essential data from the database at every request.
What if, to reduce server memory, we want to put certain variables, or certain types of variables in our database. The session facade could be made to leave some things on disk, some in memory. A little brains can be added without touching the rest of the application.
What if we want to write a log event every time something goes in and out of the session scope? The session facade is basically our only option for this. The only other way would be to search our code for the word 'session' and add a cflog on each event. With a session facade object, we can do logging or any other type of thing all in one place. Not bad.
Perhaps we may want to cflock each session access because of some potentially unsafe code reading and writing to one variable - we can do that easily here by exclusively locking the set method and readonly locking the get method, using a unique session key to name the lock.
In summary
In summary, the choice to use a session facade should be based on the risk of drastic session scope change. The benefits seem to be a lot of 'what if' scenarios, but they could happen, maybe, while the drawbacks seem to pay off right away. Laziness now or laziness later?
We've all heard it a thousand times. "VAR YOUR VARIABLES !" But why? You say, "I've never had that problem" and I'll tell you what, you probably wouldn't know it if you saw it. Pay attention here.
Let's take a simple ColdFusion function, easy stuff here. Dead simple.
<cffunction name="runMyCode">
<cfset result = 1 />
<cfloop from="1" to="5" index="i">
<cfset result = result * i />
</cfloop>
<cfreturn result />
</cffunction>
<cfquery> tags in there which could even be on a different server, maybe component instantiation calls that have to go to disk to pull in the CFC in, compile it and call it. While Java waits for the network or the disk or whatever else, it handles the other requests that are waiting.<cffunction name="runMyCode">
<cfset var result = 1 />
<cfset var i = 1 />
<cfloop from="1" to="5" index="i">
<cfset result = result * i />
</cfloop>
<cfreturn result />
</cffunction>
I've got a few of these types of entries lined up. If you have a blog, post your own!.<cflock name="#createUUID()#" type="exclusive" timeout="30">
This code creates a uniquely named exclusive lock - that's an oxymoron. If the name of the lock is unique every time this code runs, the cflock will never lock anything until somehow, magically, createUUID() returns the same value twice, within 30 seconds (right, not very likely).
Adobe has graciously granted a copy of ColdFusion 8 to the AZCFUG, and, by physical proximity (my site is on their server), Dopefly has been updated to CF8.
Amazingly, this is the first application I've gotten to work on CF8 with, and it's about time!
Thank you Adobe!
There, I said it. I'll say it again. ColdFusion is a DSL. A Domain Specific Language.
What does that mean? Is it still a programming language? It means it's a programming language meant to solve a specific problem, and solve it well. It's meant to be limited. It's meant to do one main thing, to solve one problem.
Sorry, let me say that agin. ColdFusion was meant to be limited. It's not a good tool for desktop applications. It's not a great language for managing huge amounts of data. It's not the platform of choice for creating build systems. It has never been used to compile itself (afaik). It has its limits, and they should not be crossed. Of course, to mix metephors, if all you have is a hammer, make lemonade until the cows come home, by all means.
ColdFusion is meant to be the dream language for web applications. Its original goals were to make your HTML web site database-enabled and dynamic. That goal was basically perfected with version 1.0 and the cfquery tag.
That's why we use it, people. That's why we like it. It's a DSL for HTML.
Now granted, it's so much more, now. It's been called the duct tape of the internet. No other platform that I've used can so easily and quickly connect things and people together. CF has really grown up, especially in the last few years. It has ways to add extensions to the language itself. It has added OO. It interacts with Java, .NET, C++, SMS, email & email servers, http, ftp, exchange, directory services, file systems... 98% of everything you need to build a successful web app, for nearly any purpose. As I said, it's so much more, now, but it is still, in essence, a DSL.
It solves the problem space almost perfectly. For HTML jockeys like myself, it was a natural extension, some 10 years ago now. It's not everything, but it doesn't need to be. It's not supposed to be. I hope it never is. But, for what it does, nothing beats it.
I hope you all enjoyed reading this little series on the strange and interesting things you can do with ColdFusion's components and functions. Here's a quick summary.
Part I, I introduced the subject and gave a basic intro to the public (this.*) and private (variables.*) scopes of a CFC.
Part II, we discussed violent encapsulation intrusion.
Part III, we talked about adding, changing and removing methods in a CFC instance.
Part IV, I gave you the bad idea of having the same method alias run different functions, depending on where you called it from.
Part V, I left the weekend with an actual good idea, safe API updates via function aliasing.
Part VI, we talked about the different ways to inject functions into a component.
Part VII, I discussed duck typing and how others have done it.
Part VIII, there was a fascinating example on functional programming with CF.
Part IX, yesterday, I showed off inverting a CFC, making the private interface public.
Part X, today, is this summary.
I wish I'd had the time to make one on some of CF8's new toys, but those will just have to wait :)
Again, I hope you enjoyed this series and I hope someone out there learned a lot. Have a great holiday, Merry Christmas and God bless, from my family to yours.
Here's something I toyed with years ago, revisited. In CF, you can turn your objects inside-out, making all the private variables and methods public. Just take a dash of part II and a little ingenuity and you get this:myCFC = myCFC.getVariables();
Or, from within the CFC itself, or via a injected/attached method, you can do this:this = variables;
This will replace the public interface with the private one. Hmm. I would never recommend doing that in real life, though maybe for debugging in a development environment.
CFML acts a lot like Javascript, really. In this series, I've been throwing around functions like they were candy. Indeed, ColdFusion and CFML let you do that. So let's have some fun with it.
function add(n1,n2) {return n1+n2;}
function subtract(n1,n2) {return n1-n2;}
function doSomethingWith2Numbers(thingToDo, n1,n2) { return thingToDo(n1,n2);}
writeOutput( doSomethingWith2Numbers( add, 5, 5) );
writeOutput( doSomethingWith2Numbers( subtract, 5, 5) );
Just the fact that you can is awesome.
The best benefit I can see right now for tossing around functions as arguments is for late-binding actions. You compile a handful of things to do, then execute them at the last possible moment. I like this approach for generating UI elements from OO systems in particular. We set a bunch of preferences, then, when you call render(), the system spits it out based on different code generation methods that were previously defined. That's one of my favorite things: instead of asking if a switch is on or off, just execute the method resting in a function reference.
I actually found another good use for all this fun I've been having with CF's dynamic nature.
What if you want a component to implement another interface when your application is running? What if you are trying to do duck typing and want to make sure your component really is what it is supposed to be?
In my previous post about mixin methods, I touched on a method of mixing an entire component into another, essentially merging the two. This is great for a lot of reasons.
For duck typing, if you're attempting to pass one type of object into another, no matter what type of object it is, just so long as it has the required functions, this is both a way to make one object quack like that other object, and to validate that it should quack alike.
If you are keeping a typed system and you want to pass one type of object into a system that is expecting another, you can make an object of that type, inject the current state and methods into that object and return that object in place of the other. Wow, yeah, I can't actually imagine doing that, but it's great that it's possible.
Robin Hillard had the same idea, but in reverse (and also 3 years ago), where you pass your component to the component you want to duck/quack/emulate. This makes more sense actually, that way you don't have to cheat and introspect the private variables scope, it's available, but all Robin's methods are only set on the public scope of the original object. But it's six or half a dozen.
Even still, this isn't the best way. Joe Rinehart came to the same conclusion I do (but almost 2 years ago), and that is to use ColdSpring to set your CFC via mixin method. He makes some good points, too, and it is a solid sounding solution.
(jump break)
One thing Joe brings to light is the thought of what a mixin consists of. Is it just functions, or does it include properties (public or private)? I would argue both, but that one mixin should never overwrite anything in the resulting (aka more important, aka duck typing, not the duck typed) object. Joe thinks it should be just the functions.
Here's a bad idea! Go typeless, then mix all your components together into one super-everything beast. Mix in your DAOs with your services, with your business objects. Wow. it can do everything. Then you only have one object in memory. Yeah, no idea why you would do that either. BTW, watch out for identical methods that do different things. Maybe it would be nice if you have a handful of service objects, like a UserService, a PreferencesService, etc., you can mix those types all together, then you would have a single, unified service layer.
Yeah, still not a good idea, but I could almost envision doing that.
But not quite.
We have been playing with the concept of mixing in methods, or injecting them into CFCs voluntarily or not. Here is a list of ways you can dynamically assign methods to components.
Include method
The easiest way to get common functions into multiple CFCs is to place them into a .cfm file and simply cfinclude the file. Place the cfinclude basically anywhere within your cfcomponent tags. The constructor area (anywhere not in a function) is the best place.
The greatness of the cfinclude mix-in method is that you set it basically in stone when you code it. It's a concrete thing and it doesn't change as it is executed, just like typing the functions into the CFCs themselves. I have used this for common setters, like a setUtilities method, where I wanted to inject it on a number of different unrelated objects, but didn't want to type it more than once, and it didn't make sense to extend a common component.
Cheap injection method
This is one I covered previously - you can just set another function onto the public interface of a CFC. That function will now have access to the private variables of the CFC. You can, for example, make a getter for an internal variable that shouldn't have a getter. It's a cheap hack, and works great.
Sneaky injection
I call this one private scope injection. Much like the above method, but you create a getVariables method and inject the function into the private scope.
The greatness of these two methods is that they are dynamic ways to hack into components. It feels dirty to me, but it's possible.
Single function mixin() method
Somewhat more of an official way to do it would be to create a mixin function inside a CFC that takes a function name and function as arguments. The method will then set the function into the appropriate scopes. This is pretty clean, and hey, you can somehow inject the mixin() function itself.
Entire component mixin() method
This is where mixins actually start to become useful. You can merge one CFC into another. Make a function that accepts a component as the argument, set the public "this" struct items to the current "this"scope and force some introspection to set the private variables into the current "variables" scope.
We'll talk more about this last one next time.
Here's something I did a few months ago. What happens when the names in your exposed API are too confusing? It's been published, now it's too late to take it back, and now millions of other developers (ok, a handful, if we're lucky) who depend on our object would cry foul if we changed it. What to do, what to do?
Well, why not just rename the method? Ok, rename is too strong a word. How about copying a pointer? Oh yeah, that's easy.
<cfset variables.getMethodWithStandardName = variables.getMethodWithFunnyName />
<cfset this.getMethodWithStandardName = this.getMethodWithFunnyName />
There we go, now you can go about using an updated API while leaving the old API in place and not breaking any backward compatibility!
Here's an interesting idea. Probably not a good one, but check it out. What if external calls to a CFC method execute something different than when you call that method from within the CFC? It's easy. Here's the code:
<cfcomponent>
<cffunction name="init" access="public">
<cfreturn this>
</cffunction>
<cffunction name="privateMethod" access="private">
<cfreturn "This is a Private Method!">
</cffunction>
<cffunction name="publicMethod" access="public">
<cfreturn "This is a Public Method!">
</cffunction>
<cfset this.genericMethod = publicMethod />
<cfset variables.genericMethod = privateMethod />
</cfcomponent>
Now private calls to genericMethod() will give you the private method message, and public calls to myCFC.genericMethod() will return the public method message.
I honestly can not think of a use case for this one. Got any? leave a comment.
Using the code from the previous entry in this series, Fun with Functions and CFCs II, we can take the example further and inject a new method into a CFC:
<cfscript>
function methodToInject() {return "This method was Injected";}
myCFC.getVariables ().injectedMethod = methodToInject; // inject a method into CFC "variables" scope
myCFC.getVariables().this.injectedMethod = methodToInject; // also into public "this" scope
writeOutput( myCFC.getVariables ().privateMethod() ); // call private method from test.cfc
writeOutput( myCFC.injectedMethod() ); // call injected method
</cfscript>
We injected the method into both variables and this scopes so it would be available internally and externally.
Even more useful, you can replace existing functions:
<cfscript>
function h4x0r3d() {return "This method has been hacked!"} // create a 'hacked' message function
myCFC.getVariables().privateMethod = h4x0r3d; // replace privateMethod() with this function
</cfscript>
The next time anyone makes a call to privateMethod(), they will get "This method has been hacked!"
And deleting:
<cfscript>
structDelete(myCFC.getVariables(), "publicMethod"); // delete publicMethod from internal variables scope
structDelete(myCFC, "publicMethod"); // delete publicMethod from internal variables scope
</cfscript>
We had to delete it out of the public and private scopes (this and variables, respectively) - each scope had a pointer to the publicMethod() function.
Now, with a persistent component, like an application-scoped object, this can have long-lasting effects, but there could be many good uses for it, for example with an application lifecycle altering event such as a database crash, you could switch out calls to the database to instead return empty queries or a message.
Truthfully, it would probably be smarter to replace the entire component such as with a strategy pattern.
There are a lot of fun and interesting things you can do with ColdFusion components that languages like Java just don't let you. This is part 2 in my series to explore the interesting things that you can do with ColdFusion components and functions.
Before we begin, let's make a test CFC - here's the one I'm using; Test.cfc:
<cfcomponent>
<cffunction name="init" access="public">
<cfreturn this />
</cffunction>
<cffunction name="privateMethod" access="private">
<cfreturn "This is a Private Method!" />
</cffunction>
<cffunction name="publicMethod" access="public">
<cfreturn "This is a Public Method!" />
</cffunction>
</cfcomponent>
Now we'll make an instance of it in a plain-jane .cfm file:<cfset myCFC = createObject("component","Test").init()>
Now here comes the fun part. I want to get and execute the private method from the .cfm page. Not allowed, right? Not exactly. let's make a free-floating function in my .cfm file (this could be done with a cffunction tag, but I like the familiar script syntax):
<cfscript>
function getCurrentVariables() {return variables;}
</cfscript>
If I call getCurrentVariables() now, it will return the current document's variables scope, which consists of a reference to that function and to my CFC instance's this scope, but what if I put that function onto my test CFC's public interface?<cfset myCFC.getVariables = getCurrentVariables />
now, myCFC.getVariables() gives me the variables scope of the CFC! if I dump myCFC.getVariables(), I can see everything that's going on inside. Woah, now I can play with the internals all I want.#myCFC.getVariables().privateMethod()# returns "This is a Private Method!"
I was reminded to blog something I've been thinking about and playing with for a while from the CFTalk List, so I'm starting a blogging series on the fun things you can do with dynamic languages, specifically with ColdFusion. This is part 1. We won't go over anything truly revolutionary in this series, but I do hope to invoke some good brain activity.
Before I get to the really fun stuff, I need to make sure we're on the same playing field, so this first entry is just instructional.
ColdFusion Components (CFCs) Intro
CFCs are ColdFusion's answer to object oriented programming. They allow some OO-type syntax borrowed from CF's big brother Java. They allow access modifiers of Private (can be called only from within the current CFC instance), Package (can be called from CFCs in the same directory), Public (can be called from any CF code on the server) and Remote (Provides the entry point for web services, flash remoting, Flex messaging and invoking a CFC directly from a URI).
Public Vs Private - the clever trick
When you instantiate a CFC (be it using createObject, <cfobject> or <cfinvoke>), ColdFusion, in the background, creates 2 structures (structure = struct, aka hashtable or map, aka name-value pair object, a collection of in-memory variables and data), one called Variables and one called this.
(jump break)
Variables is the private variables scope - methods and properties that appear here are not publicly available. Just like a .cfm page has a variables scope, shared with any cfincluded files, the variables scope is internal to the CFC, shared with any functions. The danger here is the old var your variables problem - if you don't specify a scope in a CFC, just like in a cfm, your variable will be set in this variables structure and can interfere with other seemingly independent functions that end up sharing the same Variables. All of your public, private, et. al. methods will appear here. Also, any variable you place in the variables scope is recognized as private.
This is the publicly available scope. Any methods you mark as public will appear here as well as in the variables scope. To set a variable here, you have to explicitly set it into This. Conveniently, the Variables struct actually contains the This struct. From within the CFC, This is located at variables.this. Externally, it is the only thing visible. One thing you will see in CF is <cfreturn this /> - this returns the public interface for an object, essentially returning the object itself from a method you called, for chaining methods. It's extremely popular with a CF standard practice, the init() method.
So this is the clever trick. Variables = private, Variables.This = public. I've never heard it done like that before, but it does work nicely.
Tomorrow, the real fun begins.
This is one I never thought I'd see, but unfortunately I have seen it a few times.
Think twice when you extend a class/component! In ColdFusion, that would be with the extends attribute of the cfcomponent tag.
When you extend a component, you are saying that that component, the one you are writing the "extends" text into, is a type of the component you are extending.
Ok, let's have an example.
Let's say we have a logging component. We say: myLoggingService.log(message); and it does it for us. Easy enough.
Also, we have a user component. User.setName(form.name); User.save();, and it saves it somehow. Basic stuff, easy to grasp.
Now, how do you write a log message after you save a user? There are, of course, dozens of ways to do this.
The way you should NOT, EVER under ANY circumstances do, is say that the user extends the logging service. That doesn't make any sense. Is a user a type of logging device? I certainly don't think so. A user doesn't write logs, a user has a name and probably knows what object to call to persist itself. The logging service writes logs. That logging service needs to be its own separate entity. It just doesn't make sense any other way. You can call it from within the user object, or better yet, from some kind of controller or service layer, but don't integrate it too deeply within an object that it doesn't need to be deeply coupled with.
Oh I know, it's a matter of convenience, you can just say log(message);. Oh wow, it saved you 17 characters, but you missed the point entirely.
The correct way is to leave the logging service by itself, then call myLoggingService.log(message). I think it's somewhat a matter of style where you call that from, of course be consistent. The rule is this: Favor composition over inheritance. Your User object can be composed of a logging service (among other things), and you should do this whenever possible.
Now, if you have a database logging service, this is a prime candidate to extend a more generic logging service. Or how about an error logging service? Those are types of logging services. Inherit up from a generic implementation, down to a specific one.
Jason Delmore, the product manager for ColdFusion, aka the "CF Insider" asks What do YOU want next for ColdFusion?
This topic comes up every couple years. Hmm... yes, always seems to be right after a major version release. Bug reports are trickling in and the team is getting antsy for something new to work on. I've gotta say, it seems like they answered almost everything I could have wanted in CF8, so it's time to dream a little bigger.
I already see some really good comments, get on out there and tell him your opinions!
Recently I decided to become interested in software quality. Let me assure you, it's not something you gravitate to when you're cowboy coding for thrills or something you decide to pick up because the cool kids are doing it. No, this is something you have to decide to like.
I said I decided this recently, so here are a couple of my early thoughts on the subject.
Web application testing tends to focus on the front-end. If you can see it in a browser, that's what you need to test. Or at least that's what I hear a lot of. Of course this testing is great at revealing missing requirements and catching exceptions, but that's the same testing we used when we tested our HTML pages in the 90's.
Come on now, is this a web site or a web application? Am I making a script or a system? Do I serve pages or programs? I certainly like to charge my clients based on the latter.
So how does testing change when you consider applications opposed to pages? This is the question I've been pondering, and I am still working on my conclusions. One partial answer is the unit test.
A unit test is an automated script that calls methods on an object. It helps to have a unit test framework that can run the tests and tell you the results in a pass/fail style (there are a couple for CF). The framework can run a number of unit tests all at once to give you a view on your overall system.
Something notable from The Pragmatic Programmer, tip # 66, "Find Bugs Once," meaning once a bug makes it past you, the developer, and appears for someone in QA or, worse, a customer, add that bug to your unit test to make sure it never slips by again.
The bright red glaring issue in this space is the lack of testable software. How do you make ColdFusion applications that can be driven by TDD? Is OO the only answer? Can you unit test a .cfm file? How can I unit test a legacy (CFMX6.0) application?
I'd like to hear what people are doing. Comment below or blog your own experiences in reply. Thanks!
More later, like I said, I am now interested in the subject :)
ColdFusion 8 is available!
I can't wait to start real development with the new CF8 features. And who wouldn't love the huge performance increase, debugging and seemingly magical AJAX tools?
By the way, now is the best time ever to switch to Eclipse, if you haven't already. The ColdFusion 8 Eclipse plugins are a huge help to the already popular CFEclipse plugin.
Big thanks to the teams at Adobe who gave us nearly everything we ever wanted with this one. Now the big question... what could possibly be next?
This is more for my benefit than anyone's, since I can never remember where this is, and I'm left Googling in the dark. This is a link to Brandon Purcell's blog entry on Preventing browsers from caching ColdFusion Pages. Ok, I'll never forget again.
Thanks Brandon! - I wish you would blog more :)
This is a final reminder that the Ben Forta Phoenix meeting is tonight! We've got a huge crowd of developers showing up, so it's a great chance to network. Lots of stuff to give away, most everyone will end up with something. Parking is a little limited due to construction, so come early or park at Fry's Electronics across the street.
The event starts at 6:30 at the UAT in Tempe, AZ. Map.
Also, there's a raffle system - you get a ticket for pre-registering at www.azcfug.org, one for filling out a survey when you get there, and then you can give some cash to the CFUG for more, so bring a few dollars and you'll have more chances to win the big prizes.
Last, some of us will probably head to Aunt Chilada's directly afterward to catch the end of the Suns/Lakers game, grab some drinks (lemonade is a drink) and talk about the presentation.
Here's a tip - checking the Unicode checkbox in the CF Admin for your datasource only actually works when you have <cfqueryparam> for your variables.
Traditionally, col = '#content#' doesn't work to insert, say, Chinese characters unless you put an 'N' in front of the content: col = N'#content#'.
When you use <cfqueryparam> for your data, you lose the ability to place that 'N' in front, therefore, we have the checkbox, hidden under the advanced settings for your DSN, shown here:
When you check the box, you may expect it to universally work with all your nvarchar and ntext data everywhere, but it only works where you have implemented <cfqueryparam> tags for your content (which probably should be everywhere, anyway).
A little problem I thought I'd share very quickly today. I was modifying an XML file in ColdFusion, adding attributes to some nodes, then later on XMLSearch()ing for nodes with these new attributes. Well, long story short, node.xmlAttributes.code="abc" will output <node CODE="abc"> And, you guessed it, XPath is always case sensitive.
The solution is to either fix your XPath queries (umm, sucks?), or write your xml attributes like so: node.xmlAttributes["code"]="abc"
There's been a fair amount of talk recently about choosing an application framework for your ColdFusion applications. The general consensus seems to be "Just pick one, already. It doesn't matter!" Well, contrary to popular opinion, picking the best framework is something that needs a lot of thought.
Consider this. The average CF developer came from an HTML background. Maybe, just maybe, a little javascript, but mostly HTML. CFML has a familiar feel and the ease-of-use is just off the scales, especially for making your first apps: feedback forms and basic content management.
This basic CFML developer now knows 2 computing languages.
The choice to learn a framework will push the boundaries of their emerging brain cells. A domain specific language (aka DSL, thx Peter Bell for this great term), such as a Mach-II XML config file, will force a 50% jump in the number of programming languages known. It's much easier than their first and second languages, but still, quite a chore.
Fusebox has 2 DSLs, the fusebox.xml file and circuit.xml files. Model-Glue Unity has 3 because it includes an ORM and an IOC object container.
Further, most frameworks encourage (some strongly) object oriented development practices. This alone can be a nightmare to figure out (much less with practical application) ideas like encapsulation, polymorphism and inheritance.
No. For your basic CFML developer, picking a framework is a big deal. Depending on your framework choice, you could be forced to double your programming language knowledge.
I'm not saying don't do it. Not whatsoever. I'm a huge proponent of frameworks. Everyone should have a few under their toolbelt and know when and how to use them. I'm also a huge proponent of learning as many programming languages as possible, which will be a tremendous help, even just for writing CF. I'm just saying, it's not that easy for first-timers.
According to his comment (#36), Sean Corfield will podcast. This is great news for people like me, who both have long drives to work and are horribly addicted to anything podcast related.
We can't wait for it, Sean!
I just have to share. It's closed source for a project I probably can't mention, but I needed to blog this. I wrote an English to English translator. That's right. I, Nathan Strutz, being of sound mind, have programmatically translated US English to GB English. I hope I'm the first, at least the first to do it with CF. Thank you. That will be all.
(Discuss with Disqus!)Rupesh Kumar lets us in on a little secret. Yes, we all know CF is Java. And we know you can call Java methods on strings from your plain old ColdFusion code. But I didn't think about doing it on Arrays until today. Thanks Rupesh!
(Discuss with Disqus!)This month (late by a week, so next month) for the AZCFUG, I will be doing an intro to regular expressions, taking you from the very easy stuff to the hard stuff, and explaining everything along the way. If you come, expect to learn! Then, expect to hang out, as we hit up Aunt Chilada's for some drinks. Our group manager, Alan Rother, is making sure we have handouts for everyone. You will take something away from this presentation, be it my charming wit, a regular expression cheat sheet, or maybe, just maybe, something bigger (more in a bit).
Some of the questions we'll be answering are:
What are regular expressions?
Where would I use them?
How do I validate a form with them?
How can they speed up my development?
Why would I, and how do I backreference?
What is lookaround?
On a scale of 1-10, how much better do regular expressioins make the world?
Last, (this is the part you're waiting for) Alan mentioned that because this is probably the last AZCFUG of the year, we're giving a copy of ColdFusion MX 7 Standard Edition. That's free, folks, a $1,300 value. You just have to be present and be luckier than the rest of the crowd to win.
Mark it on your calendars, Wednesday, November 1st, 2006 - Nathan Strutz on Regular Expressions at the UAT in Tempe, AZ.
* I asked Alan about moving it to Nov. 1, and that should work. He just needs to check with the UAT, but that should be easy.
One of my favorite bloggers, Sean Corfield, wrote that he wanted to see a way to invoke ColdFusion from the command line. A day or so later, Ashwin Mathew wrote how to do just that using cURL. It basically just hits your CFC path using the url invoking syntax (?method=myFunction&arg1=abc).
This doesn't really satisfy me.
It forces you to expose CFCs in your webroot, forces you to have them access=remote, and has the potential to force network access, especially if your site is using host headers or if you are accessing it via a public domain name.
It seems to me, a cleaner way to do this would be to invoke your cfc via an event gateway, and, because there is no command-line event gateway type (yet), I'm thinking a socket gateway may just be the way to go. Think about it, it's local, won't require network or dns access, connects directly and can send/receive feedback inline. Of course, telneting to it is cumbersome, so a simple jar or script that you could call seems logical. Depending on the implementation, you could even allow it access to any cfc or cfm on the system. Calling syntax would be something like:
java -jar CFCLISocket.jar com.mysite.myapp.myobject.mymethod(abc)
Simplify that through a shell script or batch file to make your life easier.
The Java behind it would make a socket connection to 127.0.0.1 on a specified port and send the code you want to evaluate as a string to the event listener.
A slightly cleaner way to do this would have to be through a custom gateway specifically written for command-line invoking. It would execute the same, but the jar to invoke would be even easier to write (and potentially safer).
The best imaginable way would still have to be real actual support written into the CF server. I imagine this would be like php, where you can execute a php page straight from the CLI. Nice feature, steal it!
Of course, all of this is theoretical. Big help, I know, for those of you out there looking for an immediate solution.
Today on Damon Cooper's Blog, you can read about the new tags from the CF engineering master Rupesh Kumar that give you simple, easy and effective threading control straight from CF. No more messing with event gateways, trying to execute applications from the file system or make 0-second http requests back to CF, now you can do it inline.
What's amazing is New Atlanta just announced these tags for the upcomming Blue Dragon 7.0 a little over a week ago at CFUnited.
Yeah, maybe it's blatantly ripping it off, but the tags are not from Adobe, they're just Rupesh's side project because he thought it was cool. Personally I hope they do make it back into the core of CFMX 8. It's a great idea whose time has come, and I'm glad someone thought of it.
Still within 24 hours of CFWheels and Model-Glue betas comes the Fusebox 5 beta 2. I do a fair amount of Fusebox 4.1 work, so I am personally vested in this framework.
Of interest in this version is the new CFC calling syntax, a new <appinit> tag, and new, hopefully not too confusing, modes (development, production, development-full-load, development-circuit-load), plus a strong handful of bug fixes, general updates and performance improvements.
Now, if we could just get new a beta of Mach-II before the end of my work day today, that would pretty much round everything out, wouldn't it?
Joe Rinehart just released the first Model-Glue 2 public beta. I think I had to subconsciously shut down part of my brain to cope with the video he released a couple days ago. Amazing. I have been waiting on this release for a long time, and I can't wait to start playing with it. Thanks, Joe!
So, as we all go into framework sugar-shock in the coming weeks, probably leading into the CFUnited conference, prepare to be overwhelmed. I will make sure to post my experiences here, and I hope you all have that special place of your own.
One word of warning though, the download is over 10MB, and over 30MB when decompressed. One has to wonder, so let's take a quick look. As a quick reminder, Model-Glue 2 includes everything you loved from the first one, plus ColdSpring, plus Reactor, plus new features like scaffolding. Each framework has a hefty amount of documentation and sample projects. Over 3600 files in over 300 folders. And most of that is due to Reactor, specifically the Reactor documentation. Looks like there's a few files too many, which is probably just a full export from the Reactor SVN server. I won't complain about too much documentation.
Rob Cameron just released CFWheels 0.5. Take a look at it, it's really coming together. I knew it was coming eventually, and now here it is: Rob has put in some Ruby on Rails style scaffolding. That's a lot of work, good job, man! Fascinatingly, the whole thing really looks similar to CFoW's older cousin, RoR, but the instant-admin thing makes it 10 times easier and nicer.
One thing that really strikes me is that his documentation is the best I've ever seen for a CF framework. Screencasts, pdf downloads (read the "Building your first app"one), and an online help file. Others could really learn from this. (don't point at me - hey, if anybody gets me a copy of Captivate or Camtasia, I'd love to do them for everybody :)
Another thing Rob is pimpin' is called Hadron. It's like yum or apt-get on linux systems, but for CF. It keeps your frameworks and other 3rd party packages up to date. Interesting stuff, though I can't say I'd love to use it without a gui.
The week-long AZCFUG coding contest ended last night. It didn't create a lot of buzz, so we just had 3 submissions. They were: an AJAX chat client, an employment listing, and, well, mine.
I went kind of overboard. I rewrote the site using Fusebox 5, Coldspring and Reactor. I fixed a couple security issues and made some admin tools for managing content.
In the end, Sean won on points (judged on UI, coding style and usefulness), but, the nice guy he is, conceeded, saying "I would just feel bad if I beat Nate". They added an effort column to my scoresheet and multiplied by 100. So, long story short, I won! The prize? The Adobe Web Bundle.
I put a heck of a lot of work into the site, but it went quickly. About 16 hours (my wife will say otherwise). You can see it here, and make sure to try out the admin area (i've disabled the admin security). You can play with the content and email template editors, it's ok.
Thanks everybody for voting for me! You're too kind! I reeeeeally wanted to win :) Thanks!!
Update: conceded, not the same as forfeited, I used the wrong word, thx Sean.
You may remember Mark Drew as the lead developer from the CFEclipse project. Well, he's probably one of the busiest CF developers out there, as he's just started a video podcast, pefect for your 5g iPod (ok, perfect for mine), or just for you to watch in iTunes. His first episode is his presentation on Model-Glue and Reactor.
Clicking around the CFEclipse site, I also noticed, very under the radar, Rob Rohan has got his own podcast rolling out. Not necessarily so CF related though.
Ok, so we've got Mike Kruger with his occasional CF Muse, Hal and Jeff with Out Loud, Bryan and Michael with the every-other-week Coldfusion Podcast, Matt and Peter with the Coldfusion Weekly, then Mark and Rob with their own podcasts.
Ok, I have too much to listen to, and these are just the CF related ones. This doesn't include any other java and dotnet programming podcasts, lost podcasts, general tech and video game podcasts, and half of these are video feeds. I'm really enjoying this.
Sean Corfield mentioned this entry from his blog on the Fusebox 5 dev mailing list. I had read over the entry the other day when he posted it, but I'm still only grasping the relevance of it.
Putting the extensible in XML, it almost looks like Sean is calling Model-Glue THROUGH Fusebox5. Now, how exactly does that work? Ahh, it's the beauty of those lexicons - they're more than meets the eye, apparently.
There's been some buzz around the community, but it's still on the down-low. It's an open source project that's getting people excited. It's Reactor, by Doug Hughes. Reactor is an ORM framework (Object Relational Mapper), meaning it transcodes your relational database into objects for you to use in your CF programming. Or, to state it another way, IT WRITES YOUR SQL CODE FOR YOU. (How can I be more clear?)
What? Oh that sounds like auto-generated code - Run for the hills! No, Reactor is different. It's better. The objects it writes let you do what you want with them, and its XSLT code generation gives you even greater control. Furthermore, it takes advantage of best practices for data access layers. While the internals may seem complicated, the API is simple and robust. Most developers will be able to pick it up in a few minutes.
Using it is simple. Describe the data relations you want to use in the Reactor xml config file using the very obvious hasOne and hasMany tags, instantiate the ReactorFactory object and ask it to create your gateway, objects, and so on. Save() this, delete() that, all in a day's work for Reactor.
One thing I'm starting to see is people using Reactor as the entire model layer of their MVC applications. In a large-scale app, it probably can't be your entire model layer, but it can do most of the work.
Doug is an absolutely fantastic coder, and he's doing a seriously great job on this. Really, truly, very, good. Thank you Doug!
Intrigued? Your next step should be to download Reactor, or check out the source (svn://www.alagad.com/reactor), go through the samples and docs, then read Brian Rinaldi's great getting started guide. After that, join the mailing list, get involved, talk about it with your homies.
As a last note, watch out for API changes - It's alpha software, mostly stable, but constantly changing. If you lock yourself into the API (things like createRecord), there's a good chance it will change (the naming conventions for records, specifically, are changing).
This is somewhat old news, but I've been using it lately, and figured I'd put a little reminder out here. Whenever you are trying to create a regular expression in ColdFusion and are having trouble with it, or if you're trying to use an advanced feature that just doesn't work (like lookbehind), remember that there IS a solution.
Here's a hint. Remember, CF is Java! Here's how to exploit the wonders of java.lang.String:
<cfset str = "This is my string!">
#str.matches("^.+$")#, displays YES
#str.replaceAll("\W","")#, displays Thisismystring
<cfdump var="#str.split("\W")#"/>, dumps an array of words
I've been thinking about frameworks a lot lately, if you couldn't tell. Something that really struck a nerve in my original post, for me, was Ruby on Rails' Scaffolding. The idea is pretty simple. In 1 line of code, a developer can spit out a form page that simply and easily matches up with a database table. It creates, in the background, an entire CRUD application, just like that.
I would venture to say that this is the driving force for RoR. It's popular because it greatly eases the prototyping phase, and gets developers a good start on creating their real web site. Scaffolding is why people say "wow" when they look at Ruby.
Now let's talk ColdFusion. We have got, pretty well, everything short of this one scaffolding area, at least as far as the public domain open source framework community. Why is that?
There are a few answers. For starters, we're afraid of scaffolding. We have it in our heads that we build enterprise applications, and scaffolding (as well as automated data abstraction layers, some frameworks, etc) take the enterprise performance and stability away from us. Maybe it will. Maybe we won't trust the code it can create.
Another reason is just simply that no one has done it right yet. Either it hasn't been open source, or it just looked and felt wrong or unusable, or it couldn't be customized right, or whatever. Nobody has done it right. Not yet. Any attempts have been and killed off for lack of interest.
I suppose this is where my call to action would sit, so without further ado... It's time, ladies and gents, to embrace automatic form and site generation, though in an obviously more CF way. We can do it better. We can put the Rapid back in RAD.
So, 2 things to ponder... how do we do it, and what do we call it?
More on this subject later.
A couple of responses to my recent entry about the state of OOP in CF:
Ryan Guill had a good response about the need for us to become better programmers before we marry ourselves to any frameworks, which is a valid point. The comments further his point that we don't want people working on frameworks unless those people know why they are doing it. This is always a valid question: what problem are you trying to solve by using a framework? The same principal works for design patterns, language and development platform choices, development tools and so on.
Sean Corfield has some great input about some of my points. The all-in-one framework one, in particular, he says is just a bad idea. Truthfully, I can see it both ways.
There's a lot of frameworks, and we shouldn't discourage the use of any that do their jobs well. Saying that one is the only one to use would discourage others in thinking for themselves and making informed choices.
On the other hand, how many conversations have we had in the last year on various lists about "which framework should I use?" It would be nice to solve this for once. I personally know developers who don't choose to use one because it's not clear when and where to use which framework. Sometimes even I fall into this category. Something as simple as a chart that lays out the frameworks, where they all fit in and how to tie them together would be so, so useful. I've got an idea for this, I'll keep you posted.
I concede that there is no one-size-fits-all framework, but there are a lot of folks out there still scratching their heads.
I'll continue on this subject later - thanks, everyone for your feedback, both in comments and in blogs. I'm enjoying the discussion!
In case everyone hasn't seen Ryan Guill's little project COAL (stands for the ColdFusion Open Application Library), I suggest you check it out. If for nothing else, then just for the sake that it houses the entire CFLib.org UDF library, in an easily digestable component model. There's a couple extra little treats in there too, none of which interest me nearly as much.
Ryan, if you're out there, keep it going! Add more components, diversify a bit. See if you can get Mossimo Foti's great CFCs embedded into COAL, or hook up with the OpenXCF project to package a lot of their projects into an easily digestable COAL form.
I'd love to see COAL as a standard thing you install with any new CF server, you know, install, enter serial, setup dsn entries, install COAL, register custom CFX tags, etc.
Seriously, I think there's potential here.
So Dopefly's web host decided to upgrade their servers without telling anyone. Wasn't that special? Glad to have my site back up, and apparently without losing anything in the process. That's a relief. I know, I know, I get what I paid for, but I'm happy (enough) with my $5/mo cf host. Yes they're terrible, and totally unreliable, but it's kind of an adventure, not being able to rely on databases and servers.
The site was actually up for 3 of the 4 days without a database, and yes, this is a fairly heavily data-driven site. How is it possible you might ask? Through the wonders of scope caching. Somehow when I built this site, I knew this would happen, so I'm glad to see it's paid off.
Now normally, a CF Cached query will time out at a certain time, or worse, never, without clearing all the cached queries on the server. With a good scope caching strategy, you can save recordsets in the application scope until the scope is cleared.
What I did was save my data in my query caching CFC, with regular interval timeouts (like 24 hours). If the query errored, I would increase the timeout by a minute and return the previously cached version.
Another advantage of this strategy is the ability to remove any cached entries when an update is made. When I click the submit button on my blog form, it inserts the record for this entry and invalidates my cached recordsets that will be affected by the change. The result is an instant update to would-be cached data.
Now the reason why Dopefly was down yesterday was because they reset the CF server. There goes my cached application data and my site. So now I'm devising a strategy to persist my cached data to disk (evil grin).
I know, I know, "Geez Nate, get a better host." But it's kind of exciting, living on the edge.
Client variables in ColdFusion are flawed. Inherently from the start, they're no good to use. First off, where are you going to store the data?
Registry: Don't do this. Especially if you intend on having users on your web site. This expands your registry and will make your whole server slow.
Cookie: Don't do this (see 6.3). Limitations in browser cookies keep you from storing large amounts of data. Maxing out browser cookies can have (very!) unforeseen consequences. This also will increase your network traffic and bandwidth.
Database: Don't do this. Constant updates and heavy traffic will kill your database (and thus cf) servers. Come on people, there are better ways of storing data in the database.
A couple other annoyances and pet peeves of mine are:
As a remote viewer from the AZCFUG meeting of the BOF Model-Glue framework meeting, I've got to say, that was an unimpressive breeze presentation. Sorry Joe and Steven.
The first 15 minutes were intermittant and choppy bits of audio while we waited for Joe to download and install the breeze powerpoint plugin. Can yo. ...r me n.w? The next 15 minutes had pretty good audio and was a nice introduction to the M-G framework, skipping by things we already know (like what's a view), and starting to get into the gritty fun stuff.
Then the plug gets pulled. I guess they only booked the room until 10:00pm because the hotel manager kicked them out in a hurry. Sure they weren't so disappointed, they ran (didn't walk) to the bar, leaving us sitting in coldfusion confusion.
Not to say they didn't try. They did a great job organizing the event, you know, 'A' for effort. Maybe you can make up for it next month, because we're all still interested. Seriously, maybe this wasn't the worst Breeze presentation ever, but I've seen better :p.
So, what did I learn about Model-Glue? It looks like Mach-II, it's more implicit, less explicit, to get started you should edit the modelglueapplicationtemplate's config file and follow the examples in the documentation folder. Sadly, that doesn't really tell me why M-G is better than the rest, or what development advantages it has over Mach-II or even Fusebox.
Thanks to John Blayter and the rest of the AZCFUG, the evening wasn't a total loss, and I think everyone got a free book, a Macromedia pen (I will never run out of reading material and writing utensels as log as I attend), and some pizza.
Quick tip, something i just stumbled upon.<cflocation url="?action=abc">
This will break Safari, adding the URL field to the current address. So, if you are looking at:
dopefly.com/?action=123
and run across the above cflocation tag, you will now have something like:
dopefly.com/?action=123?action=abc
Not exactly the desired effect! The fix, of course, is to be a little more specific.<cflocation url="/?action=abc">
Steven Erat has started a weekly news podcast for the ColdFusion community, highlighting news topics, software updates, interesting threads from CF-Talk, and more. This project has got a lot of promise, so support Steven by hitting his blog and downloading the first show, and hooking up your podcasting software if you've use it.
It's too bad Steven's a Macromedia (soon to be Adobe) employee, or he could probably give us some opinions on the merger from the inside. But then if he wasn't on the inside, I guess his opinion wouldn't really be any better than anyone else's.
Despite impending doom and the end of the world, etc., etc., I think this is a great time to upgrade your CF servers.
Yesterday, MM released the 2nd cumulative updater for CFMX 7.0. CF7 has been out for two and a half months with no big showstopping bugs found, just some little things about the new cfreports. Nothing urgent, just something about verity searching. No serious security threats, just something about nested transactions. No loss of performance or server stability issues, just something about web services I'll never use.
Despite those nasty rumors that CFMX7 was built on the same stable engine as CFMX6, I am forced to agree, it is stable and, yes, even production ready. I'll start pushing my superiors for an upgrade.
At least I can still look forward to seeing what hits the fan when the next DataDirect drivers are shipped.
Good job, Macromedia. You guys did a good job...
Macromedia? Adobe? Macrobe? Adobedia? Macrodobia? AdoMacrobedia? Please don't announce Coldfusion CS. CS sounds so weak.
Ben Forta Announces the launch of the CFMX7 WACK. Whack yourself if you've never read one of these books, or bench-pressed one.
This career-enhancing legal stimulant is guaranteed to take beginner and intermediate developers to the next level. I've always recommended this series, so I'm sure the latest edition is nothing but the best.
(ps. I know, I know, 2 posts in one day, what am I thinking?)
Well CFMX 7 is out already. Good work MM folks. It looks pretty seamless with my existing apps, and I can't wait to start using the new application events. Hopefully we'll upgrade our Enterprise licenses and I'll get to play with event gateways too.
Now down to business, Is there really any reason to upgrade? Yeah new programming toys are nice, but we've been doing fine without them so far. CFDocument will please the higher-ups, as will the built-in script protection, but how about a magical ability to keep JRun from crashing from too many queued threads? Does it have that? What about invincible database drivers that won't choke up? What about a connector that stays connected to IIS, finds out if it gets disconnected (starts throwing JRun errors) and re-connects itself. I've had to restart IIS and/or CF way too many times.
I'm not going to say that CF isn't enterprise-ready, or that it won't scale, because it is and it will. It always will, depending on how you code your sites and tweak your servers. I just have a few reservations.
Anyways, we're probably not going to upgrade, at least not the majority of our servers, unless there's actually something more than neat features.
Hey here's a marketing idea for Macromedia. Put out a service pack early, only a few bug fixes, whatever's blaringly obvious. Do it in a month after the release date so you can say you've fixed any initial release problems. How many people and companies wait for Microsoft's SP1 or 2 before investing in a new enterprise OS?
As a side note, I think the excel format on cfdocument will probably win us over in the short-term, but that's just for our intranet. Strange, I never really liked the idea of calling an excel spreadsheet a 'document'.
Weird little thing I found. I thought it up a couple weeks ago when the cf-talk list was bickering about CFCs and good encapsulation and so on. Here's a way to undo it all in one quick swoop.
A CFC can expose all of its private data. Just have a method return variables. Every private member and method is now yours for the taking.
Hey here's some bad coding advice. Too lazy to make getters and setters for all your variables?
<cfset myCFC.getVariables().privateVar = "new value" />
Test out Thursday's post, the Viagra Expression, with the Viagra Expression Testing Page.
It's pretty basic, but I plan to fix it up a little more when I have less people living in my house (friends and family for the holidays, should clear out by next week's end).
Rob Cockerham of cockeyed.com has inspired me. After reading his report on Viagra spam, titled There Are 600,426,974,379,824,381,952 Ways To Spell Viagra, I realized that I needed to develop a regular expression that can handle every misspelling possible. Well, it looks like I'm getting close.
Here is the RegEx so far:
The next version of ColdFusion will have a much-requested feature called Application Events. Much like ASP and ASP.NET, CFMX "Blackstone" (code name), will have events for:
OnApplicationStart
OnApplicationEnd
OnSessionStart
OnSessionEnd
OnRequestStart
OnRequestEnd
OnRequest
OnError
Looks like the community will have to re-invent their best practices again. I for one look forward to it!
Here's some good advice for you CF programmers: Learn another programming language.
Yes, that might sound strange. No, I don't mean for you to get away from CF. ColdFusion is a great language, very versatile, very scalable, very strong. I'm just saying, if you want to to be a good programmer (of any language), you should know or learn another language.
This is my story.
I was introduced to CF as my first and only programming language. HTML doesn't count and neither do simple SQL select, update and insert statements. JavaScript didn't really make sense. The company paid for an Allaire "Fast Track to ColdFusion" course in Seattle, so I was set. 2 years later, I was still using CF, but looking back, I wasn't "getting it" fully.
Fast Forward to 2002, my employer decided it was time to switch to ASP "classic". That never happened, but I did spend 6 weeks reading and practicing my VBScript skills. On about the 3rd week (yes, i'm dense), something clicked and I suddenly got it. All of a sudden there was a difference between CFML and programming. I'd never made the jump until then.
Ever since, I've learned VBS, VB.NET, C#, Java and JavaScript like they were nothing (well, aside from vb's crappy syntax, and OO programming hurdles). But better yet, it gave me the ability to learn.
It sounds like an all around good thing to me. Increase my marketability, increase my knowledge, make me more valuable to my employer, give me a better understanding of the programming world around us, and make me a better ColdFusion programmer.
If you're not a solid programmer, or you think you are but only know CF (like me), take some time to learn a new language. It will pay you back 100 times.
Just for fun, here's a list of my CFLib.org contributions:
deleteCFCache
sleep
randomColor
randomColorShade
randomColorClose
arrayOfStructsToStructOfArrays
I hope you like them!
download queryCache now.
QueryCache is a way to have more control over CFMX's default query caching mechanism. While CachedWithin and CachedUntil work great for static queries, what is the best way to cache a query that will change frequently? The answer is queryCache.cfc.
Instantiate the queryCache object like this:
<cfset queryCache = createObject("component","queryCache")>
(note: I store it in application scoped CFC's variables scope)
Cache a query by running this instead of a cfquery tag:
<cfset myLocalQueryItem = cachedQuery("getThings", "SELECT * FROM table", "myDSN",createTimeSpan(1,0,0,0))>
The first field is the cached query's unique name, the second is your SQL statement, 3rd, your DSN, and last, an optional timeout period.
Flush a single cached query like this:
<cfset cachedQuery("getThings")>
where the only parameter is the unique name of your query.
Other queryCache functions:
<cfset isQueryCached("getThings")>
<cfset getCachedQueryKeys()>
Special features:
Cached a query based on a timeout or until it is explicitly deleted.
If a re-connection to the database fails, queryCache uses the latest cached query it has in memory.
QueryCache has been running on Dopefly.com flawlessly for over a month. I originally created it because my database server is up only half the time, and I wanted to improve performance. I am distributing the code free of charge with no license. Use it at your own risk, i'm not responsible for anything that happens when you use it.
download queryCache now.
I've been playing and tinkering just a bit with the Alagad Image Component. It's a nice tool, but making thumbnails with it is tricky, and the output tends to be ugly. Here's my work-around for resizing an image with this thing.
imgWidth = image.getWidth();
if (imgWidth GT 500) {
image.blur(int(image.getWidth()/500));
image.scalePixels(...);
}
One thing I think more developers should know is the ease of changing the debugging info in CFMX. Obviously you can flip a few switches in your CF Administrator under the debugging settings, but did you know you can actually edit the debugging files and create your own?
My favorite trick is to dump the queries. Rarely do we ever select data, then display it all, just as it came out of the database. Instead we use it here and there in the page, or display pieces of it. But what does your data actually look like when it comes out of your DB? Let's make a customized debug script and solve this problem.
Navigate yourself to your debug folder, usually %cfdir%\wwwroot\WEB-INF\debug\, and make a copy of the classic.cfm file. Call it dump.cfm.
Open that file up, and find the section on SQL Queries. You see it loops over the cfdebug_queries query object. Right before the </cfloop> tag, add this bit of code:<cfif isQuery(cfdebug_queries.result[cfdebug_queries.currentRow])>
<cfdump var="#cfdebug_queries.result[cfdebug_queries.currentRow]#">
</cfif>
Now save the file, log into your CF Admin and change your "Debugging Output Format" file to this new dump file. The next page you load will give you insight into every query on your page.
My co-worker Raff just discovered a bug with the CFQuery tag. When you set the variable for a query, and then run the cfquery tag, if the query doesn't return a recordset, your previously set variable will be undefined. Example:
<cfset qry = "">
<cfquery name="qry" datasource="dsn">
UPDATE table
SET field = 0
WHERE id = 1
</cfquery>
<cfdump var="#qry#">
<cfparam name="qry" default="#queryNew('')#"> after your cfquery call.
(Discuss with Disqus!)
Two thigs I hate:
1. White space at the top of my HTML doc, before anything loads, causing larger download sizes.
2. White space at the top of my XML docs, invalidating the XML (to some XML engines).
What can you do to avoid this in ColdFusion? Historically, ColdFusion 4 had <cfsetting enablecfoutputonly="yes">. While this works, it requires you to put <cfoutput> around everything you do want to output to the browser.
Newer still, ColdFusion 5 introduced the <cfsilent> tag. Absolutely nothing inside the cfsilent tagsets is outputted. This is nice, but for my purposes, it requires me to wrap it around the top of every page... "Now where was that cfsilent starting block?"
Now, thanks to CFMX and the underlying J2EE engine, we can use the amazingly powerful getPageContext(). Here is what I have been putting at the top of my pages and XML docs lately:<cfset getPageContext().getOut().clearBuffer()>
This successfully clears the output buffer, making it fresh and ready to start anew.