Show #162 - News, Reviews and Familiarity

ColdFusion , Frameworks Add comments

In this week's show, Dave and Scott discuss the release of FW/1 2.1 Alpha 1, Matt "the awesome producer"'s new PhoneGap book, the new weekly CFML newsletter and much much more. It's what your ears were made for.


Show Link:




A little bit about our sponsor. Host Media is, among other things, a ColdFusion hosting provider. Click the link below for an exclusive discount for CFHour listeners using the discount code 'cfhour'

Host Media


Show Topic Links:


CFML Weekly

Matt's new book - PhoneGap Mobile Application Development Cookbook

FW/1 2.1 Alpha 1

Bootstrap Designer


Is ColdFusion an 'OO' language?

FORM, URL and REQUEST scopes

Ray Camden - Stop using jQuery all of the time


Buy Stuff

13 responses to “Show #162 - News, Reviews and Familiarity”

  1. Pete Freitag Says:
    Thanks for the mention guys in the show guys.

    I'll attempt to answer your question about Abstract classes - they are useful when you are building a base class that expects you to implement certain methods. This is similar to an interface but an abstract class lets you implement some of the methods, and leave some methods to be implemented by an inherited class.

    Here's a quick example, suppose you are building a ecommerce

    abstract class PaymentGateway {

    abstract boolean sendPayment();

    setAmount(amount) { this.amount = amount; }

    getAmount() { return this.amount; }


    Now you can create a PayPalPaymentGateway, AuthorizeDotNetPaymentGateway, BraintreePaymentGateway, etc that all implement sendPayment() but can still take advantage of other methods such as setAmount getAmount.
  2. Adam Cameron Says:
    G'day guys: good podcast.

    My take on the OO thing would be that no, CFML is not an OO language because of its reliance on non-OO practices that not only historically persist, but Adobe seem keen to perpetuate: all the image functions added to CF8 and spreadsheet functions added to CF9 being examples (I think those a. They need to revise this approach and go the object / method function route that Railo has already pioneered in some areas. However as you alluded to, CFML is a language that allows the developer to write in an OO fashion. Which is fine.

    I saw Ray's comment about JQuery, and see where he's coming from but disagree to an extent. Yes, people should know how to do the underlying JS, sure, but that's not to say they should then go and do it. The suggestion to abandon support for older browsers seems a bit naive to me. A lot of people in government and in "emerging markets" still rely on older browsers, and far from being "kind" to those people, it's more a case of not wanting to limit one's market. Especially if one can simply use JQuery and then they're basically supported.

    For mobile sites though, yeah, it makes sense. Not for desktop sites.

    I appreciate the improved content:noise ratio in this week's broadcast btw (I say this mostly cos I bleated about it last week).

  3. Raymond Camden Says:
    Adam, I've reached out to Scott/Dave/Matt to come on the show and talk about things more in depth, but I think at minimum, it shouldn't be enough to just say, "I'll let jQuery worry about it." You mention older browsers, but have you looked at your browser traffic and gotten a good idea of what level of support you have? Using jQuery to just not worry about it is - to me - lazy. We can't assume IE6 is the baseline anymore.
  4. Adam Cameron Says:
    G'day Ray
    There's no assumption going on with the baseline, it's from real-world traffic, and real-world sales (or potential lack thereof, if we reduced support for IE6). I think it you deal with mostly USA-originated traffic you're quite possibly right. If, however, you deal in markets that aren't quite so... err... "consumeristically competitive" (ie: people are more likely to be running old kit), then one sees IE6 still providing an amount of traffic still worth worrying about.

    That said, my comment about govt usage is from third-party sources, so I could not comment on its accuracy. It is a statement I heard made by a source I believe, just the week before last though.

    As for "letting JQuery worry about it", you're right: JQuery is not a panacea, and I *did* stress one should be comfortable with one's baseline tools (in this case JS) before making the - informed - decision to not reinvent the wheel using the baseline tool, but to rely on a very reliable already-existing mechanism for doing the work for them. There's a balance though. If I could do something reliably and robustly (and quickly) without JQuery, I'd probably run with it. But this presupposes there's nothing else on the page that uses JQuery for more complicated and less-likely-to-be-cross-compatible stuff already. If it's there for some other reason already (and this will be likely in a lot of situations), then why *not* use it?

    Another consideration here though... if we're worried about emerging markets and needing to cater for older kit and supporting older browsers, we also need to concern ourselves with the JQuery download size too. If the user is on an older machine, they're likely to have an older connection too, so possibly dial-up. This makes one swing back to "keep it lean", and perhaps *not* use JQuery. Interesting.

    Also: people on IE6 will be getting used to a fairly bad web experience by now, so if we were to NOT cater for them, would they really mind that much, and would it still fall within the envelope of "expected quality of service" for them?

    So what's my conclusion here? Dunno actually!

    All interesting stuff though!

    Cheers all.

  5. Nathan Strutz Says:
    Hey Great show and all. You've been on a pretty good roll, lately, very entertaining. I have to say, one of my favorite things in the world is when Scott goes off on some kind of rant. Either I'm for or against whatever he's saying (I like stackoverflow!), but the controversy and passion is totally entertaining. Keep rocking guys.
  6. Sean Corfield Says:
    FYI, the iPad Mini isn't really the iPad 2 hardware stuffed into a smaller box: Same chip, admittedly, but different screen, different camera etc. Chip aside, it seems to have more in common with the new iPad "4".
  7. Sean Corfield Says:
    On member functions on objects, like myArray.len() instead of arrayLen(myArray), did you know Railo 4 provides all of that? (in response to user requests!)

    On JavaScript and OO: I definitely wouldn't call it an OO language, I'd call it a prototype-based language. For comparison, Clojure is a functional language but you can do a lot of OO things in it. The key thing, IMO, is to remember that Java doesn't define what it means to be OO - look back at Smalltalk for example and also consider Alan Kay's quote that C++ "is not what I had in mind" (he invented the term Object Oriented).

    Thanx for the (brief) coverage of FW/1 - it spawned an interesting little side discussion on approaches to environment control which was a nice side effect :)
  8. Seb Duggan Says:
    On the subject of using form variables within CFCs and other places like that, the one place this seems to be necessary is when using cffile upload.

    For some reason, this tag still requires you to pass the name of the form field which holds the file, rather than, for example, being able to pass the value returned by that form field.

    Am I the only one who cringes slightly when I am unable to separate the call to the form field from my CFC service?
  9. Adam Cameron Says:
    Hang on Seb: you don't need the form *variable*, you just need its name, don't you? Which one could pass into a method as an argument, surely?
  10. Raymond Camden Says:
    +1 to Adam. At the end of the day, "Processing a Form File Upload" can't be abstracted to "Process some random file from somewhere." I think you would want to do as Adam suggested, have the file field name be abstracted out.
  11. Sean Corfield Says:
    I was going to respond to Seb but Adam and Ray beat me to it. I would typically have a single CFC dedicated to processing file uploads and have it handle file types and validation, file renaming etc. It might also record the data in a database table, or return a struct with appropriate data for the caller to do so, depending on the application's need.

    For example, at World Singles, when we upload an image file, we automatically create thumbnail and other specific sizes of it and copy those to a specific folder path based on which web site and which user the images belong to - and the uploader component stores that data in a specific table and crates an association with that user.
  12. Seb Duggan Says:
    Adam - yes, but it has always seemed strange to me that, however much your code is abstracting, a file upload still has to reach directly into the form scope to do the upload.

    Having said that, I tend to handle file uploads exactly as you suggest...
  13. Richard Hughes Says:
    I write all my test code in a directory called scratch. :)

Leave a Reply

Leave this field empty:

Powered by Mango Blog. Design and Icons by N.Design Studio