Blog

My First Foray Into CFClient

Posted by Brad Wood
Jan 03, 2015 01:10:00 UTC

This didn't start as a blog entry.  I originally typed it up as an E-mail to Anit Kumar, Adobe's rockstar support guy who offered to help me on Twitter.  See, I'm trying to build a mobile app using ColdFusion 11 mobile technology to have a chance at winning the $1,000 prize from Adobe's little contest.  If you didn't know about it, please forget about it-- I don't want any more competition :)

So after several hours of fiddling yesterday, I got a lot of the workflow understood and working but still have some major hang ups and questions.  After I finished typing this E-mail to Anit, I thought to myself, "Self, why not make this conversation public so everyone can benifit from it?"  There's precious little information about CFClient out there already and some people like Adam C has already expressed interest in hearing my experiences-- not that I expect to sell him on CFClient or anything :)  

This is a little rambly and I apologize for that.  I'll try to blog some more organized thoughts after I get this all working.  So, without further ado... Anit, please reply here if you can just so everyone can benefit from the answers-- even if it means I'm a numbskull and did it all wrong.

What Languages Did You Use This Year? (Vote For CFML)

Posted by Brad Wood
Dec 30, 2014 23:27:00 UTC

There's an interesting project going on over at code2014.com to see what languages were used the most this year.  Now, I have to preface this by saying that I generally dislike these sort of popularity contests.  They give the appearance of something statistical, but only represent a subset of the population that's exposed to them and bothers to vote.  Perhaps I'm also just bitter since CFML seems to get shafted by a lot of these sort of things.  (See the Tiobe index for details)

But nonetheless, I've thought a lot recently about the declining mindshare of CFML in the eyes of other developers (or the complete lack of knowledge of it in some cases).  This is easily evidenced by attending a non-CFML conference and telling people that you're a ColdFusion programmer and observing the disbelieving stares.  So, I think it's in our best interests to increase the presence of CFML on the Internet in circles outside of ours where we all know it's a great, modern language used by many.  It's honestly hard to blame people for asking if anyone still uses CFML when they literally haven't heard a mention of it in 5 years.  News like the recent addition of Railo to Bitnami was huge for CFML and I was happy to see the CFML community gathered and voted it straight to the top for the entire month.

So, go vote.  Right now. it's easy, just Tweet out the names of all the languages you've used this year with the hashtag #code2014 somewhere in the message.  At first, they didn't even have ColdFusion or CFML on the list, but were quick to add it after several people on the Internet brought it up.  I'm unclear on whether they're counting "CFML" or "ColdFusion" so you might add both just for good measure. 

---------------------------

Update, Hybrid group confirmed they are looking for both CFML and ColdFusion in their search:

https://twitter.com/hybrid_group/status/550060557596766209

CommandBox Documentation Now On GitBook

Posted by Brad Wood
Dec 18, 2014 23:34:00 UTC

Luis and I are moving forward with the  documentation as a GitBook.  GitBooks are comprised of markdown files stored in a GitHub repo and can be: 

One of the coolest things is that the community can submit updates and additions to the book via the standard Git pull request process.  Just fork the repo, made edits with the Windows/Mac book editor, commit and pull. Please check it out and provide any feedback:
 
 
Also, please help us spread the word to those interested in CommandBox who haven't tried it yet.  I just finished the Getting Started Guide yesterday:
 
 
And for anyone interested in seeing how it's made, the Git repo for the book is here:

How CommandBox Has Changed The Way I Help People On The ColdBox List

Posted by Brad Wood
Dec 09, 2014 22:45:00 UTC

I spend a lot of time answering questions on the ColdBox Google Group.  Perhaps too much time, since it's all volunteer, but alas I enjoy helping people.  Often times people can't get something working in their site like they want.  It may involve optional ColdBox libraries, specific handler setups, or modules.  The best way to help them is to actually create  their setup locally on my PC and try it out.  Of course, this can be a prohibitively time-consuming process just to answer a question.  

Boilerplate Drudgery 

I do most of my development on Railo, and setting up a new site consisted roughly of the following:

  1. Add hostname to hosts file tat resolves to localhost like myProject.dev
  2. Create a folder somewhere on my hard drive to host the root of the site
  3. Add new context to Railo's server.xml using the same hostname and web root
  4. Add site to Apache w/permissions and reverse proxy and rewrites
  5. Restart Railo and Apache

Now, if this was a ColdBox site, I would also need to:

  1. Visit the coldbox.org download page
  2. Download the necessary version of ColdBox
  3. Unzip it into the web root
  4. Grab an application template, or use the ColdBox platform utilities in CFBuilder IF I have a project set up for this site.

Wow, NOW I'm ready to start replicating the user's issues.  That's a lot of work for a one-time site I'm going to delete in 20 minutes.  Now, what happens when I want to tell the other user how to set up the same site to test on their end?  I think you get the picture.  To be honest, I usually didn't bother and would just throw out a guess as to what the user's issue was.

Work Smarter, Not Harder

Enter CommandBox.  This is a CLI, Package Manager, and REPL and comes with an embedded server and a growing list of generator commands.  This means I  can open up a console and in a few SECONDS have a brand new site created in a folder of my choice with ColdBox installed, an application template generated, modules or handlers installed, you name it.  And then I just type "start".  That's it.  About 3 seconds later a browser window opens and I'm using my new test ColdBox app.  

Let's take a look at the commands I used earlier today to test URL routing to two different handlers with the same name in different subdirectories.  

mkdir myTestSite
cd myTestSite
coldbox create app myApp --installColdBox
coldbox create handler event userlists
coldbox create handler pdt\real\ldr\ldr_nm\ldr_portal\ldr_agt\event userlists
start --!openBrowser --force
server open URI="/index.cfm?event\=event.userlists"
server open URI="/index.cfm?event\=pdt.real.ldr.ldr_nm.ldr_portal.ldr_agt.event.userLists"

That created an app that exactly matched what the original poster had reported and even opened up the test URLs after starting the server.  What's even better is I actually threw those commands in a recipe file called makeSite.boxr so I could tweak the recipe and run it repeatedly like this:

recipe makeSite.boxr

This is the beauty of making something automatable!  Then, I pasted those commands back into the mailing list so the user could try the same thing I did.  And when I was done, I just stopped the server with the "stop" command and removed the directory.  It's like it was never there.

CommandBox has changed the way I develop.  Admittedly more than I ever thought it would.  Spinning up test sites, installing/uninstalling modules, or even trying out a few lines of ad-hoc code with the REPL is so easy now.  I even use CommandBox for my client work too.  I can start up multiple dedicated servers based on what I'm working on that day, and just stop them when I'm through.

CommandBox Preso and Slides for the Online ColdFusion Meetup

Posted by Brad Wood
Oct 02, 2014 19:40:00 UTC

Thanks to Charlie Arehart and the Online ColdFusion Meetup for letting me present on CommandBox. Here is the recording URL:

Connect Recording

And here is the slide deck:

CommandBox - Brad Wood.pdf

CommandBox Presentation Recording And Slides For NECFUG

Posted by Brad Wood
Aug 27, 2014 06:19:00 UTC

I was honored to be able to present on one of my newly-favorite topics tonight to the Nebraska CF User Group: CommandBox CLI, REPL, and Package Manager.  CommandBox is a brand new tool and unequaled in the CFML world.  It has the potential to really bring CFML devs up to speed with the kinds of tooling and automation that other platforms enjoy if people really embrace it and help build the community it needs to thrive.  

I had a wonderful time showing off cool features and answering great questions with the group and others who joined online.  I've also had this topic selected to present at CF Summit this year so I'm soliciting feedback (good or bad) on the slides, demos, or presentation style to help me tighten up my talk some more before CF Summit.

Recording URL 1hr 30min:

http://experts.adobeconnect.com/p8q3zuxan1j/

Slide Deck:

CommandBox - Brad Wood.pdf

Links from the presentation:

 

Slides And Recording For Chicagoland ColdBox Preso

Posted by Brad Wood
Aug 14, 2014 09:10:00 UTC

I'd like to thank the Chicagoland user group for letting me present on the ColdBox MVC Platform tonight-- I had a great time.  Here is the recording URL and slide deck.  Be forewarned, I spent most of my time building a simple ColdBox app from scratch that showed bare-bones usage of MVC, models, logging and caching.  I'm ok with that though, I always prefer to show via examples than boring slides :)

Show Recording

http://experts.adobeconnect.com/p6x8qi42zml/

Slide Deck

ColdBox Platform - Brad Wood.pdf

I'm Going Commando at CFSummit! (With CommandBox)

Posted by Brad Wood
Aug 02, 2014 21:19:00 UTC

 

 

 

I'm very honored to announce that my topic "Go Commando, with CommandBox! CLI + REPL + Package Manager for CFML" has been selected for this year's ColdFusion Summit  Last year's inaugural event was a big success in my opinion and filled with great people and great topics.

 CommandBox is a new command line tool for ColdFusion developers that allows for all kinds of cool automation and package management.  It's the first of its kind in the CFML space and I'm actually writing it as we speak!  The link above has a sneak peek video of some of its features and by the time CFSummit rolls around I'll have even more cool stuff to show like dependency management and task runners.  Here's the topic description:

Go Commando, with CommandBox! CLI + REPL + Package Manager for CFML

A software craftsman is only as good as his or her tools, and quite frankly-- most CF developers' tools suck. For years CFML developers have relied on IDEs and text editors for their work, but what about when they wanted to spin up another server, install a library, scaffold out another site, perform a repetitive task, or just try out a snippet of code? The answer is that they did it manually. And what if they needed to do it again the next day? It was the same old story! Even though CFML as a language has modernized over the years, other platforms have advanced in the arena of developer tools while many of us still sit at work all day staring at the same glorified text editor. If you've only ever used CF, you probably don't even realize what you're missing, and it falls in 3 main categories:

  • Power and expressiveness of tools
  • Sharing and acquiring code with the community
  • Productivity through automation

A GUI may provide the lowest entry barrier and initial intuitiveness, but it always comes with limits and restrictions to what you can do, and how easily/quickly you can do it. A Command Line Interface (CLI) is a common paradigm with a simple interface that can support any number of commands for all the common tasks you perform on a daily basis like creating new bits for your application, running tests, installing 3rd party libraries or starting a server. Another useful ability is to be able to run ad hoc CFML code without needing to spin up your CF engine. What if there was a simple text-based API that ran the same on Windows, Mac, or Linux to do all that?

Quick, how do you install the latest version of library XYZ into your site? (Please tell me you're using other developers' hard work and not writing everything yourself). If your first thought was "open up a web page and download a zip file", stop right there-- Brachiosaurus just called and he wants his workflow back. Other platforms have made their name in perfecting the art of gathering community libraries into one standardized format that can be searched for, manage dependencies, and downloaded with a simple command anywhere and any place. Forget the zip files-- what if you could just type "install XYZ" and go get another cup of coffee? And that ABC library that XYZ depends on-- don't worry it will be automatically installed as well.

Some of your day-to-day tasks might not seem so bad. So you create a new site for each new client every month with the same defaults and base libraries. You manually check every couple of months to see if any of your libraries have new versions. Every day you run your unit tests a few dozen times. And every time you need a new controller you copy the last one you made so you don't have to look up the method signatures again. Every one of those tasks should be scriptable and repeatable-- work smarter, not harder! What if you could create a "recipe" for a new site with all the goodies you like and just run the installation and setup with a single line of code to guarantee it was the same every time? Or what if running your BDD test suite was as simple as typing "testbox run"? You don't have time for boilerplate activities all day long, that coffee isn't going to drink itself!

A CLI, REPL, and Package Manager aim to help you be better, faster, and more powerful at everything you do. Come "up" your game and discover the power of CommandBox as part of your new everyday workflow. Go Commando!

ColdBox Preso for NOVA CF UG Slides and Recording

Posted by Brad Wood
Jul 17, 2014 20:53:00 UTC

I'd like to thank Dan Fredericks and the NOVA CF UG for asking me to come and present for them last night.  I was given the floor to present whatever I wanted to regarding ColdBox as part of their History of CF Frameworks series.  I had a great time and was happy to be able to talk about some of the exciting things coming up in ColdBox's future as well as some demonstrations of CommandBox, the new CLI, REPL, and package manager for CFML developers.

Here is the Connect recording of the session:

http://experts.adobeconnect.com/p9tt6w78ldy/

And here is a PDF version of my slide deck: (1.3 MB)

ColdBox Platform - Brad Wood.pdf

ColdFusion And Railo SuperClass's Switch "this" Between pseudo-Constructor and Init()

Posted by Brad Wood
Jun 19, 2014 17:53:00 UTC

I noticed an interesting behavior this week that was a little unexpected.  The repro case involves two CFCs-- one extending the other and involves where the "this" reference points to.

Constructors

ColdFusion has two types of constructors-- that is, ways to run initialization code upon the creation of the component.  The first way is called the pseudo-constructor and basically refers to ANY code inside the component that is not part of a method. That was the only way to run initialization code back when CFCs first came out in CFMX 6.  The second way is via a method called "init()".  This was a widely-used convention for years before CF9 started automatically calling it for you when you used the "new" keyword and "entityNew()" function.

Narcissism or Schizophrenia

Sometimes components want to know about themselves or even talk to themselves.  Heck, I wrote a CFC last week that just won't shut up!  That's why there is a keyword called this available inside every CFC.  This is the same as the external references held by the code that created the component instance.  The pseudo-constructor and init() method both have access to this.

The Code

Here is our super class, or base class.  

animal.cfc

component {
	
	writeOutput( 'Animal pseudo-constructor. "this" name: #getMetadata( this ).name#<br>' );
	
	function init() {
		writeOutput( 'Animal init. "this" name: #getMetadata( this ).name#<br>' );
	}	
}

Here is our sub class or concrete class that is a more specific type of animal.  

dog.cfc

component extends='animal' {
	
	writeOutput( 'Dog pseudo-constructor. "this" name: #getMetadata( this ).name#<br>' );
	
	function init() {
		super.init();
		
		writeOutput( 'Dog init. "this" name: #getMetadata( this ).name#<br>' );
		
		return this;
	}	
}

Remember the new operator will automatically call the init() constructor method.

index.cfm

<cfset new dog()>

So as you can see, each component logs the name of the component as reported by getMetadata() in both the pseudo-constructor and init() constructor.

The Behavior

Here is the output.  It is the same for Railo 4.2, CF9, CF10, and CF11.

Animal pseudo-constructor. "this" name: animal
Dog pseudo-constructor. "this" name: dog
Animal init. "this" name: dog
Dog init. "this" name: dog

The this reference in both init() methods point to the "dog" component that I'm creating.  However, the pseudo-constructor code in the base class "animal" has a this reference to "animal", not "dog". What bothers be about this is:

  • The this reference changes unexpectedly in the base class
  • There is no way for the base class to access the concrete class in its pseudo-constructor
  • I can't find any Railo or Adobe ColdFusion docs that reference this behavior to show if it's expected or not.

That second bullet point is specifically what was tripping me up because the base class can't get a reference to the actual component being created.  Sean Corfield mentioned on Twitter that a base class should not know about it's sub classes, but use polymorphic methods. However that DOESN'T WORK since the base class's pseudo-constructor has no reference to the sub class at all.   To test this, put a speak() method in the dog CFC:

function speak() {
	writeOutput( 'Woof!<br>' );	
}

Now, try to call that from the base classes pseudo-constructor.  

speak();

No matching function [SPEAK] found

Of course, this works from the init method, but my point is I think it should work in both constructors.

Another interesting note is that if you save a reference to this in the base pseudo-constructor and check it later, it will have changed to the concrete class.  This made debugging a pain since I originally started appending references to an array in the request scope and dumping them after the component creation which yielded different results than the state of the this references at the point in time when the constructors were executing.

Conclusion?

I mentioned this on Twitter and got a couple different responses. What do you think?  Should CFCs handle the this reference the same between their pseudo-constructor and regular constructor?

 

Site Updates

Entries Search