Is Adobe ColdFusion Web Application Construction Kit series bad for new CFML developers?
Posted under: 
I remember when I started programming ColdFusion fresh out of college in 1999. I had a 3 day HTML class which was my first exposure to HTML, then read books. I would "buy" the Dummy series, then exchange the unmarked book for a more advanced book on the same subject covering ColdFusion, SQL, and HTML. The Adobe ColdFusion Web Application Construction Kit (CFWACK) book was my bible along with a ColdFusion video series.
Flash forward to today, would I recommend a new developer learn ColdFusion with the CFWACK book. No, the content has been updated for ColdFusion releases but the methodology has not. It seems to still teach on a procedural methodology not Object Oriented approach. Is Adobe ColdFusion Web Application Construction Kit series bad for new CFML developers? Yes, it teaches how to create a mess with unmaintainable code UPDATE 2: And ugly code (see comments below about using script). We aren't developing one off web pages anymore but complex web applications. Even though the title says "web applications" the book misses this point.
On Amazon, I looked inside Vol 1 and the first CFML code the reader is exposed to is one template with a query, html, cfoutput in "Introducting ColdFusion". I am guessing Chapter 11: Creating Data-Driven Pages and Chapter 14: Using Forms to Add or Change Data are the same procedural mess with the dreaded display/action page methodology. It appears the first mention of ColdFusion Components (CFC) is Part 5, Chapter 24. UPDATE 1: I had searched v2, not v1. It appears the first mention of ColdFusion Components (CFC) is in Chapter 11 "The Basics of Structured Development". Also CFWACK series is huge, Vol 1 is 600 pages, Vol 2 is 600 pages, and Vol 3 is 640 pages.
This being said, I would recommend several ColdFusion books for new CFML developers.
ColdFusion 9 Developer Tutorial
Object-Oriented Programming in ColdFusion
ColdFusion ORM
Adobe ColdFusion 9 documentation set (pdf/html):
Installing Adobe ColdFusion 9
Configuring and Administering Adobe ColdFusion 9
Developing Adobe ColdFusion 9 Applications
Adobe ColdFusion 9 CFML Reference
** You were able to purchase the Adobe ColdFusion documentation set for a ridiculously low price around $50 but I am not sure if it is still printed with the most recent ACF release.
Not Adobe but Railo 3 Beginner's Guide covers CFC in chapter 3, about 70 pages into the book.
As one of the authors of CFWACK, I'll say you're missing the point. CFWACK is about teaching you about the entire Adobe CFML "stack" vs how to build a web app. Consider many of the chapters as individual cookbooks, if you will.
It is akin to reading Eloquent Ruby yet wanting to learn how to build a web app in Rails.
Just my 2 cents. ;)
I totally agree with you. I learned on "Web Application Construction Toolkit for CF3.5" and by reverse engineering the tools in ColdFusion Studio none of which really exist anymore. I think in an effort to sophisticate the language they've left some of the simple beauty behind
Just because something is 'procedural' does not mean that it is 'bad' or difficult to maintain. Just because something is 'object oriented' does not mean that that it is 'good' or easy to maintain.
I have seen beautifully written apps that were a pleasure to maintain that would be considered 'procedural'. I have also seen horribly written apps that were a nightmare to maintain that would be considered 'object oriented'.
These books are not really meant for advanced developers. You need to crawl before you can walk. You seem to want people to start sprinting before they can even crawl. That, in my opinion, will lead to even more nightmarish applications. Baby steps, Mike, baby steps.
Finally, you are 'guessing' at how Chapters 11 & 14 discuss how to handle things? And then decided to write about what you 'guess' and present it as 'fact'? I am not saying that those chapters do not present the material the way you 'guessed', but, you should know for sure before making statements like that.
Although I see your point, sometimes I feel like you have to learn how to add and subtract before you can use a calculator.
I agree with your recommendation on John Farrar's "ColdFusion 9 Developer Tutorial" over the CFWACK based on starting out with a modern, structured approach to building web applications. Part of the reason CFML has such a bad rap today is because of the unstructured procedural mess that is so common - and the CFWACK doesn't help there.
I'm not sure I'd recommend Matt Gifford's "OOP" book for a full beginner. I think it's a great book for the long-in-tooth, procedural CFer who needs to learn the basics of OO in a gentle way but I don't think today's n00bs need it, if they start out with Farrar's book or if they learn in an environment that uses a framework (well, a _modern_ framework, i.e., not Fusebox).
Thanx for the kind words about the Railo book: Mark Drew put a huge amount of work into that and I think he's done a good job creating a well-structured beginner's book!
Interesting perspective John.
Pat it would be interesting to see Adobe do a Head First, In Action, or Pragmatic Programmers from scratch. Jump right into OO and Script.
Thanks Scott for catching the "guessing" I have a CFWACK 8 book which I am skimming.
** "Creating Data-Driven Pages" is procedural examples, one page, query, output, html.
** Components are mentioned in Chapter 11 "Basics of Structured Development", looks like I was searching vol 2 not 1 on Amazon.
** Form chapters teach the display, action template method.
As for sprinting, walking, baby steps, I feel other languages jump right into objects and functions for beginners but CFML doodles. Here is an example with "Ruby in 20 mins" - http://www.ruby-lang.org/en/documentation/quickstart/
Mike - That Ruby intro was pretty good, but I wonder how many people new to programming would understand it (or understand enough of it).
To me, the WACK books are good for new developers, not necessarily new ColdFusion developers. For someone coming to CF from another language, I don't think I would suggest the WACK books. However, for someone with little or no development experience, I think the WACK books are a good place to start.
Scott, kids happily pick up Ruby and Scala and all sorts of languages that are way more sophisticated than CFML. One of the best "intro to C++" books I've ever read gets folks using templates (generic programming) in the first few pages and then introduces classes. That initial approach is what shapes your thinking when you are learning to program.
There's nothing inherently hard about OOP (or FP) if you're new to programming. It's only hard if you've learned a different (procedural) approach.
I still wouldn't recommend WACK for total newbie to programming but great clarification on distinguishing between "new developers" and "new CFML developers".
Sean - I can see your point. However, I have worked with Java developers (with no web background at all) who had no idea about how forms were processed. I think the WACKs do a decent job with explaining that, from a web standpoint. Granted, it could/should be better, but that does not mean they are 'bad'.
Speaking as someone who has actually USED the CFWACK series to train personnel - here's my two cents:
1) Trainee 1 - had NO background at ALL in development - 3 months with CFWack and very little cleanup and input from me - wrote his first Enterprise Level Application - which we are STILL using now 3 years later - with only minor modifications to his original design.
2) Trainee 2 - all ASP.NET background - "Holy Crap this is make this SO much easier!"
Both of them were "weaned" on CFWack - and then were provided John Farrar's "Developer Tutorial" - and as a Team of 3 developers - we have managed to launch and maintain over 12 Enterprise Level apps that we use across multiple platforms in 3 years time. Some were "group projects" that I used to provide additional training - and some were completely one-to-one (one dev per app).
Having to deal with ASP.NET, Sharepoint, Exchange, and the rest of the MS world - I can tell you that compared to the books/learning curve for those - I'll take the WACK approach any day of the week...
Just my 2 cents from my experiences...
Don't forget CF has always been labeled as easy to learn, probably because of the tag based syntax. We don't totally want to get away from that, even if many advanced developers may want to. I think we need a paralled approach with procedural and oop...we don't do a great job at my work with either, and it is a mess...i don't think many at my work know much about oop or orm, or anything like that. Some I don't feel totally have the basics down and they have been coding for years. We need references to see how it is done from the ground up, like procedural tag based. We also then need to see the same basics using oop script orm, ect so the newer developers can see how to do it, and then see maybe a better way to do it.
I think this is a really tough topic to find one solution. I think this may be something that CF has been struggling with for years...what is the best way to go, and how best to teach people how to use it. I am glad there are multiple books out there on CF that can show me different ways to do the same thing, even if I don't totally understand all the different ways to do it. If I don't understand it, the CF community is great at helping with blog posting, twitter feedback, ect.
Mike bringing this type of topic up from time to time is probably a good thing for many developers to read, and think about, and give an opinion...I has helped me see things differently, and I hope it has caused other followers of yours to do the same.
@Scott, if Java developers have never written web apps, I wouldn't expect them to understand HTTP request/response mechanics. There's a lot of basic information out there about writing Servlets - with classes / objects - if they need it. Also, I never said CFWACK is 'bad', just that we should be teaching CFML developers a better way to write things these days.
@Dan, lots of languages have easy tutorials based on OO. The Allaire brothers created a procedural language in a world where lots of people were already doing OO. Now CFML has had OOP constructs for a decade. There's no excuse for teaching a procedural-only approach today. New developers should not learn a purely procedural approach - as I said, for n00bs, there's no inherent complexity in OO because everything is new.
As for the legion of old-school CFers who still don't know the basics of OOP in this day and age, that's why Matt wrote his book: a very gentle, very thin book, introducing the absolute basics of OOP.
I agree that it's tough to find a solution to the problem of the vast majority of CFML developers only knowing procedural code. And that makes it tough for people new to CFML - not because learning OOP is tough, but because they'll mostly be coming into environments that are stuck in old-fashioned ways of thinking about code and they'll get frustrated trying to do things the modern way... And they'll leave for other languages where developers start out learning modern ways of thinking.
That lack of modern thinking is what will kill CFML - no one will learn it because nearly all employment environments will look uninteresting / old-fashioned. CFML has essentially become the COBOL of the web: "We don't need no gosh-darned objects here! And you kids better get off my lawn!"
FWIW, I started programming before OO. I learned procedural programming (and in the 80's I also learned some FP - functional programming - which was the hot research topic back then). I started doing OO in early '92, in C++, and picked up Java in '95. By the time my team (Java and C++ guys) were exposed to CFML, it was already capable of being used as an OO language. Now old languages are sprouting functional features and new languages are appearing with full FP support, sometimes with full OO support as well (sometimes dropping traditional OO support in favor of advanced polymorphism and dynamic inheritance). We're seeing CFML taking baby steps toward that with the addition of closures in Zeus (CF10) and Appollo (Railo 4.0). Add a decent collections library and we might start seeing FP style solutions in CFML - and then procedural CFers will be two generations of thinking behind the curve... :)
Sean -Sorry about that, did not mean to make it seem that you said the WACK books were 'bad'. It wasn't you who said that, it was Mike.
When I started in web development I learned PHP. I had the luxury of having my brother-in-law as a mentor. He spent quite a bit of time trying to teach me an object oriented approach to writing code, but I just couldn't grok it. Years later, when I finally started to 'get' OO, all the stuff he tried to teach me all of a sudden made sense.
I don't agree with people who say that making things OO will make them easier to maintain (and, conversely, that making things procedural will make them harder to maintain). Whether you write procedural code or OO code, if you do not have a good process/methodology/framework in place NO code you write will be easy to maintain.
So would it be enough for the WACK to introduce CFC's and thereafter have all page code ported to a CFC?
Same code...just in a CFC. Thoughts?
//page
<cfset pdfmanager = createObject("component", "cfcs.pdfmanager").init();
<cfset pdfmanager.createInMemory() />
//pdfmanager.cfc
<cfcomponent>
....
<cffunction name="createInMemory">
<!--- Create a custom in-memory pdf --->
<cfdocument name="cover" format="PDF">
<h1>PDF created from <i>cfdocument</i></h1>
<h3><cfoutput>#DateFormat(now(),"mm/dd/yyyy")#</cfoutput></h3>
</cfdocument>
<!--- Write the PDF to disk --->
<cfpdf action="write" source="cover" overwrite="yes"
destination="pdfs/create.pdf" />
</cffunction>
</cfcomponent>
Introducing CFCs early and then using them appropriately would be "enough".
That means using VAR to declare variables or using the LOCAL scope so that folks get into "good habits" early on.
It's all about teaching good habits, rather than just spewing code into pages with no structure.
I knew someone would ding me on the missing local. :-D That was a copy/paste from my WACK examples.
I think that's a good compromise though [using CFCs].
More script examples too :-) CFML can be beautiful. Maybe that will be a post for someone else!
@Mike, totally agree that more cfscript would really help people come onboard with CFML since it would then look much more like other languages and therefore "easier" to learn (in the sense of being closer to what folks see everywhere else).
I only use tags in .cfm pages (and I keep that to a minimum - just simple loops and conditions) with all my CFCs as script (Railo supports a lot more tags in cfscript than ACF so I don't even have to resort to those weird CFC wrappers, even tho' Railo supports those too). My code looks a lot cleaner now than it did a few years back!
@awmichel said "@mikehenke I agree, procedural CFML is in most cases a complete mess to maintain, but that usually has something to do with the programmer."
Mike - that is kind of what I am saying. The level of 'mess' in code has, in my opinion, less to do with whether its procedural or OO in nature and more to do with the skill of the person who wrote it.
Mike and Sean,
I agree more script should be shown, but do it along with tags, so some of us (that have not been able to convince many employers that script might be better and cleaner ) can compare the script and tag based and see how the relate...newbies that never came from a programming background (there are tons out there like myself) can see the power of script because they can process how tag would do it and see that many of the scripts are cleaner. Maybe the examples are online and users that have the book can use a code to bring them up...using 2 monitors to reference tags in one and script in another.
I have used some script when i was converting foxPro code and it was much easier to copy the foxPro code to a cfc and just change a few things and poof it worked.
I am really enjoying this thread, learning a lot from the few people that are posting here...
Like John, I'm one of the authors of the WACK series, so I thought I'd chime in as well. It is unfortunate that the tact here isn't, "I prefer this book", but rather, "WACK is bad". I think it's great we have multiple options out there for learning CF, and I certainly would not expect one to fit all.
Sean, you mentioned that cfscript would be easier for folks to learn since it would match the other language they know, but you are making a basic assumption that the readers of the WACK series are already experienced programmers. I don't think that's the target audience. A lot of our readers are coming from a perspective of _only_ knowing HTML (with no JS at all).
I think John's comment is an excellent example of why I wouldn't always resort to script or OO to illustrate a point. If I wanted to show someone how to use cfdocument to put a PDF on a page, I don't see it as worthwhile to wrap it into a function call first. Just: <cfdocument ..> html </cfdocument>. Nice and simple. ;)
I think with all the material we have to cover, it's hard to "see the forest for the trees" in terms of getting people over the syntax and into larger concepts. It's something I'm going to talk to Forta about for the next rev.
Thanks Ray for talking to Forta about the next revision. I really like the Head First and Pragmatic Programmer series formats covering different languages and concepts. Maybe even update WACK and also publish a simpler, modern "how to build a web app". I would even go as far as using FW1 or CFWheels in it.
@Ray, both you and Scott have made the same incorrect assertion: that someone said "WACK is bad". Go back and read the post and the comments. Mike _asked_ if it's a bad book for new developers because of advances in web development and the language itself. He then went on to say he'd recommend other books. Some of us find faults in the way WACK teaches the language - because it's outdated in its approach. That doesn't make it a "bad" book, just that there are others we'd prefer to recommend. The WACK is still "the bible" for CFML - it just needs a makeover.
I also did not say "it would match the other language they know". I was still talking about programming n00bs (who know no languages) but saying that teaching language X is easier if X looks like the majority of languages out there that a n00b would find examples of. If they go searching for solutions to problems, and they find examples in half a dozen different similar languages, it's easier for them to read and understand all of those solutions because of that similarity. If you put a tag-based language in front of a n00b, it's going to look alien - unlike any other code examples they might find online - and it's going to look like a minority language (still one of CFML's biggest problems, IMO).
I know some of you guys are going to be sensitive to criticism of the book since you worked so hard on it. But you also need to recognize that web development has changed dramatically since the 90's and CFML's presentation to the world has not. Sure, it's gained a bunch of new tags but to read the WACK - and most other material out there - you'd never know CFML had evolved to allow script-based OO just like "every" other language out there...
I reread the post..again...and this sticks out to me:
"Is Adobe ColdFusion Web Application Construction Kit series bad for new CFML developers? Yes,..."
Its kind of hard to see how he is not calling the books 'bad' by that statement. Maybe I am splitting hairs, but, by saying that the books are 'bad' for new ColdFusion developers, whom I believe are the books' intended target, he is saying they are 'bad'. Logically, how can something be 'good', when its 'bad' for its intended target?
I agree that the WACK needs to address how some things are taught, needs some additional information, such as OO concepts (but I disagree that ANY framework should be taught). I think its safe to say that Mike's message got lost in the delivery (happens to me ALL the time). Seems to me, he wanted to say something like , 'Hey, maybe we should review this popular series and update it to teach more 'modern' techniques', but instead it came across, to some, as 'The WACK books suck. Read these instead'.
As Sean mentions, it is more a "teaching" not content and it could have been done more like Scott's delivery. When I was skimming through CFWACK 8, I actually thought there is some good stuff in here too bad it is so verbose and the examples are procedural/tag based (not elegant looking) and not much different then when I read it 10 years ago.
Mike, can you give a concrete example of how you would use OO in teaching something like cffeed, cfdocument, cfmail? Would you honestly put these behind CFCs and build an MVC app to demonstrate them?
I don't have examples of these three tags but here is some training material https://github.com/mhenke/CFML-in-100-minutes/blob/develop/cfml100mins.markdown
I have an old mx7 wack book. looking at the toc, it seems each part could be its own book like a pragprog books.
I'll try to throw something up some examples on github for the three tags you mentioned.
@Ray, yes, I would start right out with an MVC approach as best practice for teaching CFML. Nothing elaborate but an emphasis on Model (CFCs in cfscript), View (CFMs in tags with _minimal_ logic) and a very simple Controller concept to wire requests up. It doesn't have to be Front Controller (although I prefer that approach overall) but Page Controller is simpler to learn and is really nothing more than emphasizing separation of presentation from logic.
It's this lack of basic "best practice" that has created a generation of CFML developers who are pretty much incapable of picking up OO***. Take a look at the way Ruby on Rails and Groovy / Grails are taught to complete programming beginners - views are templates with almost no logic at all, the model is where all the "work" happens and the controllers are simple and glue things together. Basic web application structure.
The reason CFML is looked down on by other developers - and why CFML developers are considered "lesser" - is because of the lack of that basic structure in applications, in thinking and in teaching.
Another thing that's inherent in the Ruby on Rails approach (and to some extent in Grails) is testing. Unit tests are natural to folks who learn in an environment that encourages testing, where test stubs are trivial to create, and where automated testing is a widespread - normal - practice. A lot of Ruby developers don't even feel comfortable writing code first nowadays - they'd rather write tests to clarify their thinking and provide a clear, executable specification of the code they need to write. In the Clojure world (and the Lisp world in general), a lot of developers work primarily in the REPL, exploring the shape of the problems and evaluating possible solutions, teasing their production code out of those experiments - and often teasing their test code out of it too. When your project setup tool creates not only an outline of your code but an outline of the tests you should write, there is no friction to doing things the right way.
***And this is not due to intelligence or ability - it's due to how alien OO thinking is to folks whose entire career has been spent in a procedural mindset. Folks who've spent their entire career doing OO have a similar block when trying to learn FP (although, ironically, procedural developers pick up FP more easily since they don't have all that object-state-based baggage in their way of approaching problems!).
Here is a very, very bad start. I haven't even ran the pages so think of it as more sudo code - https://github.com/mhenke/wack-examples
If anyone want to help out that is cool.
I didn't flush out a Page or Front Controller. Just started using script, new function, and script functions Implemented as cfcs.
This probably opens me up to ridicule, but hopefully it shows I am not just trolling. I am one of the generation of CFML developers Sean mentions :-)
@Mike, I'm assuming you haven't run that code yet?
This comment thread is probably not the place to critique the code... And I have never owned any of the WACK books (I've browsed thru them when they've turned up as CFUG raffle prizes or I've seen them on other people's desks) so I can't sit down and create accurate transcriptions to what I'd view as decent OO practice.
I will say the hello_mail example really serves to show what a mistake Adobe made introducing the CFC wrappers for certain tags instead of working thru a proper script syntax, which is what the CFML Advisory Committee were trying to do. FWIW, Railo supports the CFC wrappers but also supports:
mail to="#to#" from="#from#" subject="#subject#" {
writeOutput( body );
}
Similarly for http, query and the other tags around which Adobe created wrappers. This is much more in keeping with lock, transaction and so on.
Haven't ran the code just started getting some examples up for Ray
Mike, I originally asked if you would use MVC to teach just a simple concept like cffeed. I see in your example code that's not what you did - you used cfscript. So I think that - in one aspect - we are in agreement. It seems silly to think one would build an entire app just to demonstrate one small feature. Again - I believe we are in agreement here.
That being said - are you then just opposed to tags _completely_? If so - we will have to agree to disagree I guess.
Sean: Well, thank you for clarifying your position I certainly do not agree. This has been an interesting discussion though.
"Well, thank you for clarifying your position I certainly do not agree." - I'm not sure which position you're referring to but I might as well assume all of them :)
I started writing a long response to this but it's drifted off topic into other, bigger concerns and I think I'll turn it into a blog post at some point.
Definitely an interesting discussion tho'...
Glad I waited till Sunday afternoon to check up on this post, I see it has a lot more input and very interesting opinions. I see MVC being mentioned...isn't it hard to use MVC for any examples since there is no standard
Adobe approved framework...I have heard this from people...other languages have standards on testing tools, frameworks, ect...i think it would be tough for CF to use this MVC or this tool if the community, or adobe have not decided on them as a standard...but this leads into a whole other discussion.
I will make the point again, I started using this language because it was easy to pick up because of the tags. I have been using it long enough were I see script would help if I used other languages, but for many people transitioning to this language, I would think the tags would give them an easy way to start using CF. Then, once we have them "hooked", I think learning the benefits of script and OOP and ORM, ect, would really help...let's get them hooked. I think it is the communities job to really help get the nOObs or the non script users to use script...i have used it a bit, but when I would places with a time crunch, it is hard to just jump into script and try to grind my way through it. That is why I mentioned a way to show me the examples in Tag and Script.
I do realize I have been using CF long enough I should know more about script, however, most companies I have worked at did not even push application.cfc, some did not push components, so it is hard to get into using OOP and script.
From what I hear from everyone, the WACK is a good book for nOObs, but may need to be reviewed for zeus to see if there is a better way to show developers, new and old the different ways to do topics...many function-tag/script could be shown with both script and tags without making the book bigger...then if the books referenced the live docs, and that could be where each function and tag/script could be expanded...i do remember someone making a blog post about how there are comments at the bottom of each tag/function where examples for each could be made...why not expand on this and show how each tag/function can be written in script, and expand more of the other topics in live docs to show a cfc function written in tag then in script...we could really make the livedocs the place to be, or at least the first place to go before blogs.
Just a few more suggestion you all can agree with or rip apart. Looking forward to seeing what you all can come up with :)
@Dan, MVC is a design pattern. It's completely independent of a "framework". MVC is a way to organize your code. CFers can use design patterns without frameworks just the same as any other language developers can use design patterns.
@Dan, a couple of other thoughts:
"most companies I have worked at did not even push application.cfc" - companies don't generally drive technical change: that's down to developers. That's part of CFML's problem: the developers often don't know enough to push for technical change in "most companies" :(
"I started using this language because it was easy to pick up because of the tags" - this is an interesting point that speaks to the question of what is the real target of CFML these days. When non-programmers want to start building web sites, what do they do today? They probably pick up a free open source CMS and build it that way, perhaps learning just enough of the language to tweak things how they want. When someone wants to learn web programming, what do they do today? The probably pick up a free open source web framework / language, so they're going to learn Python, Ruby (on Rails) or PHP.
So a question that's worth asking is whether CFML is aimed at non-programmers these days? If so, how does that sit with the increasing focus on enterprise integration in ColdFusion, the price increases, the licensing changes and the alignment with LiveCycle etc? That all speaks to Adobe viewing the enterprise as the primary market for ColdFusion. That's certainly where the money is and that's about building serious software with industry best practices - MVC, OO, ORM, etc.
It's not a question we can answer - only Adobe can answer that - but it's certainly a fair question to be asking... I hadn't even really considered it until I read your comment, so thank you for that!
Sean,
sorry interchanged MVC and framework...my bad
as for my comments about getting started, glad I could bring some less smart people thoughts into the blog post :)
My best man in my wedding was doing coldfusion back in the late 90's and he got me into CF...taught me a bit, then I took 1-2 classes, and there I was...not a motivated developer back then, but hey i was in a new city and in my 20's :)
I have learned since then to be more motivated, and try to go to conferences and contact people on blogs for help and try to learn...i am not so sure a lot of other lower skilled developers do this, especially if their companies don't push the boundaries of development. I want to learn more, but for me, sometimes I need to be pushed at work to do it, especially since I do have 2 kids at home and other interests.
I do agree Adobe has to answer some of these questions raised by you, mike and others..I know Ray can't make adobe specific decisions, but I am glad people like him and scott jumped in on this if nothing more than to continue to push the original question into different areas.
Sometimes I wish these type of "discussions" could happen more and get more people involved, i think it might be a good way for many people, including Adobe people to see certain topics for different developer perspectives...i for one saw lots of different views and have learned things for sure.
if this is the end of the blog post, it was worth getting involved for sure...
I've hesitated to respond again [wanted to get the full scope of the discussion here] but I do agree deeper development practices can be discussed but I don't believe the WACK is the outright winner for the place to do it though.
The points from above:
1) Should teach OO (at least basics)
I'm good utilizing CFCs more to get devs used to not tossing code in views but, as Ray points out, why put a one line tag into a 6-10 line CFC? The point is to showcase one simple feature, not build a system around it. For more complex pieces where there is much more going on...going to a CFC is fine. I'm also good with using a CFC to build a simple library of the examples, per chapter, in the book and the CFMs just use the CFC. That's a good look there since it reinforces the use of CFCs, which is the crux of OO dev in CF. We can also share the CFCs across chapters, if needed.
In regards to other languages teaching OO from jump, that's not outright true. They teach syntax first: loops, outputting data, etc. aside from Rails, which is a framework not the language [see Ruby books and find how fast it gets into OO dev]. Eloquent Ruby takes 10 chapters to even touch an object/class and everything in Ruby is an object. It also never touches on building a web app, just simple programs, gems, etc. The majority of the books will cover how to do stuff first and considering WACK is three volumes of cookbook'esque material, the app dev "how to's" [in regards of full app dev] get lost in the mix, rightfully so.
2) Should use script
Honestly, I think this is the worst of the suggestions for one simple reason: Adobe CF is not 1:1 script to tag. Some chapters would have script, some tags, some a mixture and the user will be left wondering which to use and when. I do believe it should be used and showcased more but not the dominate approach. Script queries can't hold a candle to cfquery, which is why use 100% tag [preference]. We would have to explain, at least I'd be compelled to, how do to both approaches so our code examples double in a book already pushed to the gills on page count already.
@Sean I do agree CF's target is an interesting discussion. I think WACK targets new-to-CF devs [hence tag use, they all most likely know HTML] and new devs. You put it best: it is "the bible". If WACK were named "The ColdFusion Bible", I doubt we'd have this conversation as those books are expected to be in this format. :)
--
Now, with all of that said, I discussed this very thing with Forta before the last book [CF9] started up. I wanted to change the book to writing one consecutive app [Orange Whip throughout, not just at the beginning] while keeping the format. So we start with basic pages, etc then pull them out to CFCs and implement new features as we go through. We have queries, forms, master-detail views, can do e-commerce in there, export PDFs for invoices/statements [or whatever], etc. The problem was as I kept talking it took the essence of what WACK is and destroyed it. In one app you probably would not even come close to the coverage of what's possible in cfpdf, cfmail, etc. Our goal is to show the full scope of each feature.
I quickly realized another book is needed for this and that's ok. It is a great thing to have more books and there should be. The frameworks need books. I've tried getting a CFWheels book off the ground but no one wanted to join me. The CF ecosystem isn't cohesive in the available books, IMHO. That's the problem...not the WACK.
[sorry so long-winded] :)
I'd like to ditto what John said. I'm learning Ruby now (slowly) and using a few resource. I've yet to see one start off with modules. It's syntax so far, and small examples.
Not saying "Well, if Ruby does it too, then it must be alright", but arguing against the notation that "all" other languages start off that way with their docs.
Personally - I'm a big believer in baby steps when it comes to introducing a new language. I like to see much smaller tidbits with very little else around it.
But that's just me. ;)
The problem with any one of us sitting around and passing judgment about which book is the best book to start learning ColdFusion with is futile, at best. We're all seasoned developers who know design patterns, MVC, OO, etc. etc. So, to us, this is the natural use of ColdFusion. We've probably all long forgotten what it is really like to be a n00b.
CFWACK is one (of many) books I use and I've bought a copy for every release since 6.1. I have my complaints about the last couple editions, but that had more to do with lack of content vs. not having the content presented in the right way - and the fact that it went to three volumes at twice the price <g>. But I digress - CFWACK is still to this day a handy desk reference to many little (or rarely) used aspects of ColdFusion. It's also a great reference for experienced developers who want the nitty gritty of new features in the latest release (though this could use more cowbell too, imho).
At the same time, I would also argue that it has room for and should include some of the suggestions mentioned here. I think it would benefit from at least a section on OO, cfscript and design patterns - it's an advanced topic, so there is no reason it couldn't be put into the advanced volume - and it would enhance the worth of the WACK tremendously for those of us who do help the n00bs get started.
As for training others, I still point them to the WACK first. Yes, it could be argued that it doesn't demonstrate enterprise development initiatives clearly, which is why I follow it up with books that do - but hands down WACK is still the best book to learn the ins and outs of the core language. John's book is also a good choice, I agree there, but it's too light. It's a good book to be used in conjunction with the WACK, and is another I recommend to new(er) developers, alongside Matt's OO book. It's really the combination of books that makes one a better developer.
I also agree with Ray - small doses of code that clearly illustrate what is going on are better than long, drawn out code examples that try to teach all the aspects of development at the same time. My eyes glaze over whenever I pick up a programming book whose first code example is three or four pages long. Tiny bits of code that demonstrate the immediate use of the function or tag at hand is easier to digest for most people, and I've never personally read an example in WACK that I didn't immediately see how I could apply it to the task at hand. Perhaps as a younger developer I may have had problems, but it's been so long... lol.
In any case, I've rarely ever picked up a ColdFusion book that I didn't learn something from. So, to call one particular book out as, perhaps, not the best choice for learning ColdFusion is being a bit nit picky IMHO... WACK is certainly not on my list of books to throw out with the bath water, but it's also not the only book on my list.
@Denard
Volume 2 has ~30 pages on scripting. I'm all for showing some OO but what parts of OO? If we go MVC, someone may want MVP or MVVM. Is using a CFC to encapsulate your code enough or are patterns the desire? I still believe that's not WACK material in the sense of a chapter just won't cut it, IMHO, and there isn't enough room for more than a chapter.
Rest assured, Ben has either read these comments, will, or, at a minimum, Ray/myself will bring it up to him for CFNext WACK options.
@John - I was thinking more along the lines of a chapter on developing an OO application framework (beans, dao, gateways, etc.) using the simplest possible methods and design patterns (facade) shown in both tag and script constructs. As for MVC - even a cursory mention of the core concepts while discussing OO would be good. I can't even begin to tell you how many MVC apps I have to work on that are full of procedural code and barely use the framework as intended. What is missing is the OO concepts for a lot of developers... so I'm merely suggesting it would make the book more relevant to today's developers to include something along those lines. Not to replace a full fledged OO design book, but enough to peak the interest and teach the average new guy the core concepts in both tag (for the new guys) and script (for the already experienced in other languages) developers.
Trust me, I'm with you Denard. The information would be great but I just do not see it as possible or worth it when there are other worthwhile books focusing on it. You mention beans/dao/gateways and just a couple years ago that whole approach was thrown out of the window. Sean even posted about it: http://corfield.org/entry/The_DAO_and_Gateway_separation_in_CFML_is_nonsense.
That's my point. If you go with one pattern/route, someone will bark about it not being the right one. MVC is a safe bet but, again, available space isn't there. It will be considered "Adobe's Suggested Approach", I believe, to which they don't have an official stance on one anyway [to my knowledge].
I urge you to read the CFCs, custom tags, and scripting sections. I especially urge Henke to read them. Judgement after a chapter/TOC skim shouldn't lead to such sensationalism but it does get eyeballs on the post though. ;-) [not that the discussion isn't good to have but merit can't be hedged on a skim; no disrespect Mike...just being honest]
Oh and LMBO @ your UPDATE 2 to the post Henke. Tags = ugly code now? :-D hehe
And I agree with Sean - it is nonsense, but by the same token it does separate the two concepts enough to make them more easily digestible by the masses, which is why I mention it #1, and having separate gateways isn't the worst thing in the world #2. I'd rather have someone doing separate DAO and gateways than neither. Besides, Matt solved that problem in his book with a simple example of how and why you might combine the two.
...and the reason why it became a "problem" in the CFML world is because developers were just copying and pasting without understanding. Literally! I had developers ping me because they'd copied an example from the Mach-II Coding Guidelines without understanding it and then they'd complain to me that the code didn't work - well, duh, it's not going to work in your application without changes! I ended up taking the examples _out_ of the guidelines so that developers wouldn't follow them blindly.
The root cause is that CFML developers are never taught any structure when they learn the language - they have no basic understanding of separation of concerns, no comprehensive of basic best practices when designing and building applications.
Re-reading the comments here I feel the opponents of changing the WACK are taking a bit of an all or nothing position: that it's not worth the WACK's trying to cover MVC or OO at all because it's too big a field and it can't cover all of it. No one suggested extensive coverage. The suggestion was to promote MVC as a code organization pattern and to promote CFCs for Model-like parts of an application. The problem right now is it provides _no_ guidance in that area. I don't think trying to thread a single application thru the whole book is a practical idea - it covers too many language features - but I think talking about applications in terms of views, controller logic and the business / application model would give a context for where features should go in a well-structured web app.
Hey all,
I keep bringing this up in my posting, why does the book have to be exclusively on paper...why can't many of the chapters/sections link to online code examples...that seems to me a way to discuss the topic in print, then the reader can go online and see the code snippet and see how it runs with a logical example. Yes this is much more work, but I bet many of the examples are already on peoples blogs and they could be combined into say the liveDocs and run from there...make the liveDocs more interactive...or something similar.
I agree many new developers are not taught with any real format...that causes me to just use whatever junky way of designing code i have always used, which is very bad. Not saying it is easy to add more to the books, but better coding design standards might help all of us learn at least one better way to design our code. I know there are lots of good ways to design our code, and groups tried to put standards together, but get the writers together and have them come up with one way, and state in the beginning of the book the standards used in this book are just one way to do it, so once you learn one good way, you can better understand how others are designing their code and maybe it would help.
Like where this post has gone the last day or 2...
Dan
@Sean, I'm with you guys mostly but for most of what is requested, the book has it. There could be more clarification/examples but read Volume 2 chapter 24, specifically page 61 "Separating Logic from Presentation": "...the CFC is a container of logic... Many developers find it's smart to keep a clean separation of logic and presentation while coding."
Shortly thereafter they show singleton use, not mentioned as such but sticking a CFC in the app scope is essentially a singleton. Inheritance and interfaces are also discussed in the same vein. Jump then to volume 3 page 52 and you'll see suggestions for code organization, the mention of frameworks [model glue, mach II], etc. All suggestions on building scalable, well coded apps.
I won't go through the whole book here but most complaints are already handled in the book. They just aren't in one concise chapter called "OO Development" and MVC isn't directly explained/showed [to my knowledge]. My main suggestion is to read the book, especially Henke [again].
@Dan, unfortunately publishers need to make money. :) Chapters 43, 44, and 45 are online: http://www.forta.com/books/0321679199/CFWACK9-2-echapters.pdf. 43 - Internationalization and Localization, 44 - Error Handling, and 45 - Using The Debugger.
Linking to blogs are a no go for reliability. People change domains, etc so you can't rely on any blog with examples but we do link to online resources [some blogs] for more information, links to good libraries, etc.
John,
sorry was not clear, i figured most of the examples could be grabbed from the blogs, to save time, not link to the blogs. I have used other books where you had to put some code from the book into the site online to use the code...i guess adding it to the liveDocs as a bad idea...
Gotcha.
John - I'll add the WACK series to my reading list but over 1800 pages over everything ColdFusion and the kitchen sink seems daunting which is why I like your cookbook suggestion for thinking of the WACK book. I think all the hard work and material is lost in the current format. The format could be divided into separate smaller, more focused books maybe the "parts" sections are a good place to start. I have said this before but I really, really, really like the http://pragprog.com/ and http://headfirstlabs.com/ series. They seem to balance focus, code, modern approach, material, and explanation very well.
I've seen cookbooks mentioned a few times so I thought I'd remind folks - don't forget Adobe has a series of cookbooks on various topics, one of them being ColdFusion:
http://cookbooks.adobe.com/coldfusion
@Henke
I haven't even read it word-for-word but at least do it justice by reading the parts backing your "it is bad for devs" stance.
I'm a HUGE Head First fan. It taught me OO through Java before I knew Java. lol. I say take the reigns and write up a proposal, get a publisher on board, and some co-authors.
@Ray
Good reminder.
I know I am likey in the minority, but I loathe the Head First books. I bought Head First Design Patterns (on a recommendation of a friend) a few years ago and after 5 pages, I threw it out. T me, those books are written & edited by people with severe ADD. :D
Haha. That's the one I loved. Granted, I read it in '04 or something like that but I was 100% green on design patterns.
John, is WACK really "good" for new cfml developers to read vol 1 (600 pages), then vol 2, 60 pages in for "Separating Logic from Presentation" to be mentioned then jump to volume 3 page 52 for organizing code.?
I think the WACK material is lost in its current format for new cfml developers but someone mentioned most of us haven't been "new" for awhile :-) Sid Wing had a comment of training and the WACK book worked with new developers.
If I want to learn about Lincoln, I am going to probably read a one book biography verses Sandburg’s Abraham Lincoln six volumes series. If I want to learn specifically about something in his life, I might pickup a volume of the series or another specific book. Compare this to the WACK series. It is all definitely very complete but is a new cfml going to want to read all the nuisances and buy 3 volumes to pick through chapters.
I can only speak about the employee I hired last year and yes...he wanted and used the WACK religiously.
I knew I was running the risk of you going back to the page number but that's fine. See what is between those pages and notice CFCs are in vol 1, vol 2 expands on it some, vol 3 goes deeper; you know...seeing as it is getting started->advanced in 3 volumes. ;)
Comparing a persons biography [Lincoln] to a tech book is weird but ok. :) It absolutely applies if you consider the one book bio being a quick reference and the six volume being a complete series for you to master all aspects of Lincoln knowledge.
@John: Volume 2 chapter 24, specifically page 61 "Separating Logic from Presentation"
Separating Logic from Presentation is the fundamental basis of a well-structured web application. It shouldn't be 24 chapters in, let alone not part of Volume 1! Similarly for "singleton use" - that should be considered basic CFC usage. Similarly for ideas of code organization - Volume 1, not the best part of 1,000 pages into a three volume set.
This underlines the exact point I'm making: for CFML developers, this basic good practice is considered "advanced" for some weird reason. That's why we have so many poorly skilled CFML developers - the definitive guide to the language pushes off fundamental material to "advanced" chapters. That we have developers who've spent a decade programming in CFML who don't have the first idea about application structure is a sad indictment of both the technology and the community...
Sean, I agree. It is a sad indictment on the community and tech. Pinning it on one book is ridiculous though.
As to when things happen, read the TOC. The pages before those others all lead up to something [queries, admin (datasource, etc), etc]. Where it occurs in the book is far less important than saying it simply isn't there. With it being there [nixing that argument from the post and other comments], the issue is now placement. #cantpleasethemall
Last words: an indictment on the community is more apt than on any single CF book. If it isn't what you [speaking all here] think it should be, change it. Sensationalism and strictly discussing [meaning no action] will leave us in the same state 5 years from now. Just saying.
Enjoyed the convo. Bowing out as it seems I'm getting repetitive and argumentative [more-so protective], when that isn't my intention or desire.
@John, "If it isn't what you [speaking all here] think it should be, change it." - that's why I've been advocating OOP, frameworks, design patterns, standards (and learning additional languages!) for the last decade...
These days it's a bit of a lonely battle: many of those who were in that chorus with me have left CFML for other technologies - and then we have discussions like this which just depress me :(
Good point on not pinning "the state of cfml developers" on one book. I am getting the feeling John mentioned about the general thread. It is still cordial and lots of different points/counter points have been mentioned.
@Sean - and your advocating OOP, frameworks, design patterns, standards (and learning additional languages!) has had a tremendous impact on the community over the years. Don't sell yourself short out of frustration with the state of CFML developers - I, for one, learned a great deal from you (and many others because of you) about these topics.
@John - I, personally, am only advocating that WACK can help address the state of CFML developers by including information that helps lead developers towards OOP and away from procedural development. The landscape was changed by Adobe dramatically with v9 - the shift from corporate is clear with 10 - more enterprise focus - more OO - more capabilities (closures, anyone?) that put CFML on par with other enterprise technologies - but if there is only the same old procedural way of doing things presented, all that work is for naught. All the efforts Adobe is putting forth to give us that enterprise quality technology will be laid to waste if all CFML developers ever do is procedural programming with it. Since WACK is 'the bible' of CF developers, and has been for as many years as I've been a CF developer, then shouldn't it reflect the same initiatives being pushed not only by the community, but by Adobe? Can't the WACK help address the situation we're faced with, where developers are falling behind in their core skills? Isn't it really a disservice to the community to allow the WACK to continue to demonstrate a primarily procedural focus when the technology itself has clearly moved beyond that? I recognize you have a vested interest in this work, and I realize you're frustrated with the mood of this thread and feeling protective - but if you're truly out to help the community, then you kinda need to put your personal feelings aside and recognize the needs of the community should be the primary focus of the WACK. I'm not knocking the WACK, I'm suggesting ways it could be made to work for the initiatives and skill sets developers are going to need to continue to be productive and remain competitive with this technology.
I think what Sean and Mike (and others) are looking for is a unified front - that we unite as a community of developers are ensure that all our works try and focus on the enterprise aspects of the technology. I'm not saying don't teach procedural development, I'm saying also teach OO along side it. I don't think that this should be an emotional thing - it seems pretty logical to me - everybody focuses on a basic set of principles in their works (blogs, books, etc.) and ultimately that will become the norm.
Last last words, since Denard addressed me directly.
1) I have 0 vested interest in WACK. I get paid a set price for my involvement [$ per page written basically] and no royalty so once my work is done the success of the book matters not to me, in the financial sense of having interest.
2) I don't think my community involvement is of any question here as I've been active since I began over a decade ago.
3) There are 0 personal feelings relayed in my comments. Please read where I agreed with Sean, Mike, and others on several points, including the inclusion of better OO practices.
I didn't plan on responding at all until I saw Mike was passing judgement without even reading it. His premise was wrong from jump, not his intentions, and I merely pointed that out.
Can the WACK do better? Absolutely. I wouldn't have talked to Ben [see above] about making changes if I thought it was perfect.
Do I take this conversation personal? Nope. I'm 100% down for discussion about what I'm involved in or otherwise but because I'm not 100% in agreement with Sean [who I highly respect] or others in this discussion doesn't make me personally involved. ;) Just read my comments in context to who I responded to and you'll see I agree with the majority of what was said except that the WACK fails to discuss OO principles. It simply needs to do it better with more meat [volume].
Hope that clarifies, as I write this with all happy intentions. lol
@John - I knew I shouldn't have gotten involved in this, lol.
I took my cue on your frustration with the last comment you posted - the rest is a result of that combined with what I felt was adversity for being OO inclusive in the WACK in many of your comments. My sincere apologies if I was mistaken in either deduction.
Hehe. No need to apologize. I'm far from frustrated [very easy going by nature].
If my comments aren't clear regarding OO inclusion, that's my fault. I'm all for it, if space allows.
So, with me being the procedural, ten year plus CF guy who needs to learn properly, at last, which book should I start with? I've used CF from v3 up until v7 a lot. I do use CFCs to separate logic from presentation but now need to be good with CF9 and learn properly. Any help would be appreciated. thanks
I might try "Object-Oriented Programming in ColdFusion". Also maybe a different language that is pure OO like Ruby so you can see how it functions and then incorporate the new ideas into your CFML.
Will do, thanks. Good comments on this page!