Contact Doug!
Learn About Doug!
View Doug Boude's online resume
updated 11/18/2009

View Doug Boude's profile on LinkedIn
Link to me!

Follow Doug Boude on Twitter
Follow me!

Be Doug's friend on Facebook
Befriend me!
(I promise not to follow you home)
OO Lexicon
Chat with Doug!
Recent Entries
You may also be interested in...
Florida web site design



Czech your Page Rank!
Check Page Rank of any web site pages instantly:
This free page rank checking tool is powered by Page Rank Checker service
Surf's Up!
Visit Egosurf.org and massage YOUR web ego!
My Score: 9,001
Doug's Books

Read (and recommend)

  • Men are from Mars, Women are from Venus
  • The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How Collective Wisdom Shapes Business, Economies, Societies and Nations
  • Blink: The Power of Thinking Without Thinking
  • Head First Design Patterns
  • Transact-SQL Programming
  • What's So Amazing About Grace?
  • Just So Stories (Rudyard Kipling collection)

Reading

  • Prayer: Does it Make Any Difference?
  • Data Mining (Practical Machine Learning Tools and Techniques)
<< October, 2007 >>
SMTWTFS
123456
78910111213
14151617181920
21222324252627
28293031
Search Blog

Recent Comments
Categories
Archives
Photo Albums
Funnies (5)
Family (3)
RSS

Powered by
BlogCFM v1.11

08 October 2007
Appropriate Usage of the "THIS" Scope
For the past several days, my good friend Jim and I have been having a series of discussions regarding the use of the 'THIS' scope within CFCs; specifically, CFCs that are to be used in an OO fashion. He's part of a small team that has just begun their OO journey and are embarking on a project where they hope to grow and refine their understanding in this arena. Jim being the stickler for correctness that he is, he often bounces approaches and ideas off of me to see what my take is, as well as compare the code he produces to that of his fellow teammates. Here is where a certain rift has manifested itself among them, as his fellow coders are producing CFCs that make heavy use of the 'THIS' scope and little to no use of 'Variables' and 'Var', while Jim is not using 'THIS' at all and is rather declaring his variables as public within the 'Variables' scope or private using 'Var'.

My personal take on the use of 'THIS' within a CFC (and what I firmly expressed to Jim) is that it would be a rare circumstance when I would see 'THIS' as the appropriate scope, since putting variables into 'THIS' exposes them to actions performed outside of the CFC. Just visualizing a CFC with all it's internal variables in the 'THIS' scope immediately causes me to think, "You've just reduced your object down to a very primitive state...a Transfer Object. Why don't you just rather create a structure to hold those values since you're ACCESSING them as if your object WERE a structure." Basically, I've been telling Jim that using 'THIS', except in very specific circumstances, is a bad thing to do.

His own intuition and experience up to this point tells him the same thing, since his comprehension of 'Variables' and 'Var' is quite clear. He has as of yet, however, been unable to convince his peers of this, and has even been admonished to STOP using 'Variables' and 'Var' and start putting his CFC variables in 'THIS'.

Because Jim is a stickler for learning to do things the "right" way, he set out on a Google journey to find documented proof that what he and I believe regarding 'THIS' is absolutely correct. His search has left him empty-handed, though, and so he and I turn to you, our fellow developers, for input on this topic.

The question then: What are your basic rules of thumb regarding the use of 'THIS' when writing a CFC to be used in an OO application (even a loosely structured one)?

Thanks in advance for sharing your opinion!

Doug  :0)
Posted by dougboude at 11:45 AM | PRINT THIS POST! | Link | 6 comments



04 October 2007
Yet Another Model-Glue Quickstart...
Jim Pickering, the manager of the Kansas City CF User group, recently started a group project to rebuild their UG's web site. The project has the secondary agenda of promoting team development and learning Model-Glue, so he invited me to participate by setting up a skeleton app with basic security and then giving his volunteers a "Model-Glue Quickstart".  The entire presentation is just over an hour long, and includes:

  • Jim giving an overview of setting up the local development environment (minutes 0 through 2),
  • a Model-Glue overview and dissection of the basic security functionality (minutes 2 through 34),
  • and the adding of a new piece of functionality to the app (minutes 34 through the end).

There are places where the visuals and the dialog got a bit out of whack (minutes 15 or so and onward), but it levels out enough to not be irritating around minute 25.

So if you're interested in yet another high speed "Model-Glue for The Rest of Us" style preso, here it be!

https://admin.adobe.acrobat.com/_a200985228/p70824254/
Posted by dougboude at 12:51 PM | PRINT THIS POST! | Link | 8 comments
03 October 2007
Model-Glue XML Isn't Valid!!! Short Reminder
Don't you hate it when you're focused on adding functionality and/or troubleshooting issues in your Model-Glue app and when you save your modelglue.xml file to see if it all works right, you get the error:

Model-Glue: C:\ColdFusion8\wwwroot\yourAppName\config\modelglue.xml isn't valid XML!

I hate it. A lot.

See if you can spot the earth-shattering error in the following snippet of trouble-causing xml:


<event-handler name="view.register">
    <broadcasts />
    <results>
        <result do="view.template" />
    </results>
    <views>
        <include name="body" template="dsp_register.cfm" />
    </Views>
</event-handler>


This has been my day to be mentally challenged for some reason, so perhaps all of you found it quickly. But fifteen minutes, several experiments to isolate the offending code block, and a visit to an online XML validator later, I was reminded that XML is case sensitive. The way my font settings are in my IDE make a lower case and capital "V" look VERY much alike, so I kept looking right over it.

Just thought I'd share this in case it helps someone else save a few minutes. ;)

Posted by dougboude at 4:36 PM | PRINT THIS POST! | Link | 2 comments
02 October 2007
And Now For Something Completely Different...

A sign I made for the bathroom stall at work...I'll let you guess why I felt it necessary.

Feel free to use it, too!


The Cat in the Hat
If you’re sitting on the potty cause your side’s about to break

And your colon it’s a rollin’ and your nether regions ache;

If you’re droppin’ logs like Enron stock with every single push,

Then please think of your fellow man and give a double flush!
Horton the Elephant
Posted by dougboude at 9:17 PM | PRINT THIS POST! | Link | 2 comments
Dumping An Object is Like Taking an X-Ray
an OOP noobie analogy
Lately I've had the privilege of helping a good friend of mine climb "Mt. OOP", and in the process have been able to refine a lot of my own knowledge. I've also discovered that I sometimes make too many assumptions when imparting understandings, and this short post is in regards to one of those items: Dumping Objects.

One thing I always urge my fellow developers to do is to form a solid expectation of what the results will be when the code they're writing is executed.  Well, what I found out is that my friend (and the rest of his team who are just getting their feet wet using objects) were certain that dumping an object should allow them to see EVERYTHING inside of it. Consider the following CFC:

<CFCOMPONENT DISPLAYNAME="FleshAndBones">
    <CFFUNCTION NAME="init" ACCESS="public" RETURNTYPE="any" hint="I return the body with a single organ">
        <CFARGUMENT NAME="initialOrgan" TYPE="string" REQUIRED="yes" hint="I am the first organ to be added to the body">
        <CFSET variables.stBody = structNew() />
        <cfset variables.stBody.organ1 = arguments.initialOrgan />
        <CFRETURN THIS />
    </CFFUNCTION>

    <CFFUNCTION ACCESS="public" NAME="addOrgan" OUTPUT="false" RETURNTYPE="void" hint="I add a new organ to the body!">
        <CFARGUMENT NAME="thisOrgan" TYPE="string" REQUIRED="yes" hint="I am the organ being added">
        <cfset var newKey = "organ" & structcount(variables.stBody) + 1 />
        <cfset variables.stBody[newKey] = arguments.thisOrgan />
    </CFFUNCTION>
</CFCOMPONENT>


Now, consider the following code which creates, initializes, populates, and dumps the "FleshAndBones" object:

<cfset objBod = createobject("component","FleshAndBones").init(initialOrgan="Heart") />
<cfset objBod.addOrgan("Lungs") />
<cfset objBod.addOrgan("Pancreas") />

<cfdump var="#objBod#" />

The expectation was that when dumping an instance of the objBod object, "variables.stBody" should be visible somewhere in the dump. When it wasn't, red flags were raised and a revisiting of the CFC occurred until, by golly, the developer FORCED that variable to show up in the dump! How?  By experimenting with scopes until he found one that allowed it to be visible: the THIS scope. Bad form, Jack. Putting variables into the THIS scope without a VERY good reason is tantamount to circumventing the very purpose of using an object, in my opinion. If you're going to do that you may as well just create a structure and manipulate that since the object will pretty much be behaving the same way. Enough on that, though.

Here is what the dump DOES contain:



To help explain what SHOULD be expected in the dump of an object, I gave my friend an analogy that helped him so much that he said I should definitely share it on my blog, so here it is:

CFDUMPing an object is exactly like taking an X-Ray of the object: You should expect ONLY to see the bones, not the soft innards. The bones of an object are its methods and metadata such as the method hints, return types, incoming arguments, etc. The soft innards are all of the variables, both private and public, that have been declared. It could also be any queries that have been executed, structures that were created, or anything else for that matter. Nothing besides the bones will ever be visible on an X-Ray, so not seeing those other internal items in the content of the dump is perfectly normal and is what SHOULD be expected.

Now, very often you WILL want to see what some of those soft innards of your object are looking like at various times. The answer to that is simply to make sure you have a method present whose job it is to return that particular soft innard, such as the following:

<CFFUNCTION ACCESS="public" NAME="getBody" OUTPUT="false" RETURNTYPE="struct" hint="I return the body!">
    <cfreturn variables.stBody />
</CFFUNCTION>


You can then dump that soft innard like so:

<cfdump var="#objBod.getBody()#" />




So in summary... CFDUMP (and the "getMetaData" function) give you X-Rays of an object. If you want to see the squishy parts, create a method that returns them!

Doug out.
Posted by dougboude at 3:03 PM | PRINT THIS POST! | Link | 0 comments