The Harmonious Programmer

First let me start off that I am not a Mac owner and therefore please keep this in mind.

One of the issues with ACF9 on Mac OSX Lion is the use of the java.awt package to get items like the list of available printers.  The AWT package is just a wrapper for a packages that are native on the target operating system.  In this case, there are bugs in the apple.awt.CToolkit class that is the problem on MAC.

We were having an issue with Mach-II 1.9 hanging on MAC Lion recently and we narrowed it done to our use of java.awt.Toolkit.  You can indicate to the JVM that you want to use the sun.awt.* package instead which appears to have fixed the issue for Mach-II 1.9 for Mac OSX Lion users.  The positive side effect is that it fixed the hung "Info" page in the CFIDE as well.

You probably already have headless=true in your jvm.config file, however you need another directive to use a different awt toolkit otherwise the JVM will default the buggy apple.awt toolkit.

Let me know if this fixes other ACF9 issues on Mac OSX Lion like cfdocument.

-Djava.awt.headless=true
-Dawt.toolkit=sun.awt.HToolkit

Update 1: This appears to have fixed generating PDFs using cfdocument as well.

Update 2: I'd like to thank Sumit Verma at Ten24Web for spending 4 hours nailing down that AWT was causing an issue in Mach-II 1.9. This is what led me down the right path to this JVM config argument change.

Update 3: Typically it is "CF9/runtime/bin/jvm.config" where CF9 is the location you installed CF.  Be sure to make a back up copy of the jvm.config in case you foo bar something.

View cf.Objective 2011 - Things Close By in a larger map

Let me know if you want to add anything on the map.  I'll add you as a collaborator!

Matt and I decied to move the ColdFusion Weekly to an archive on Posterous this week.  So I decided to listen to our last show while we ere chatting on IM and this little gem came across my ears.  I decided to transcribe it because it's worth it's weight in gold.  Bear in mind that this show is from June 2008 which is nearly three years ago.  I guess things haven't changed at all.

Matt: This timing is kinda interesting with the growing pains that are going on right now. It is obviously with all the open source going on, very - as people know from stuff I said -- it's a great time to be a CFML developer. We all need to figure this stuff out together. Some of the final things I'd like to say is that I hope that after people calm down a bit and that everybody can just be nice to each other. I'll just say that...

Peter: You know there is plenty of space out there.  We're not fighting for same square foot of land...

Matt: Yea, and the CFML community has always been a great community and we will continue to do that...  The other thing I'm starting to realize is and that is probably why you'll see me participating in blog comments less... I'm getting to the point with that a lot of people are say things that they might not otherwise say to you if you were in person...

Peter: Yea, whether your name is attached to your comment or not, there is a little additional bit of anonymity when it comes to commenting -- even if your name is there... just because you don't have to deal with somebody getting up in your face.

Matt: Right, so I guess I would say -- try to think about as if you were talking with people in person.  There is a lot of misunderstanding because of text communication -- everybody knows this -- there is no nuance to it and you don't know how people are delivering that message.  This is just one of the things that causes things to spin out of control like they have a bit recently.  Like I said, it's a fantastic time to be in this [CFML] world.  It's only going to get better for everybody involved.

ColdFusion Weekly - Version 3.09 - CFExit - 9:20-11:07

Sometimes you need to check to see if the POST or PUT content body is contains the same number of bytes indicated in the content-length header.  Remember that the content-length value is the number of bytes not the length of the content body string.  Depending on the character set encoding, some characters in the content body may have more than 1-byte per character.  It's ultra important to remember that when you check the content body against the value in the content-length header.  Also, you should only check the number of bytes when the request is of HTTP method PUT or POST as there is not content body for GET and DELETE requests.

The sample below tries to decipher the charset from the content-type header (if available).  Most REST / SOAP APIs require that all POST and PUT requests have content-type header in which the charset is usually a component value.  If your API doesn't require one, you may consider making that a requirement for POST and PUT operations.

Example

 <cffunction name="performContentLengthChecks" access="private" returntype="false" output="false"
    hint="Performs content-length header and body checks.">
 
    <cfset var content = GetHttpRequestData().content />
    <cfset var headers = GetHttpRequestData().headers />
    <cfset var contentType = "" />
    <cfset var charset = "ISO-8859-1" />
   
    <cfif StructKeyExists(headers, "Content-Type")>
        <cfset contentType = headers["ContentType"] />
       
        <!--- Find a charset in example "application/xml; charset=UTF-8"--->
        <cfif ListLen(contentType, ";") GTE 2>
            <cfset charset = Trim(ListGetAt(ListGetAt(contentType, 2, ";"), 2, "=")) />
        </cfif>
    </cfif>
   
    <!--- Check that the content-length header was sent --->
    <cfif NOT StructKeyExists(headers, "Content-Length")>
        <cfthrow type="MissingContentLength" />
    <!--- Check that the number of bytes in the content-length header of the raw content equals the header value --->
    <cfelseif headers["Content-Length"] NEQ Len(content.getBytes(charset))>
        <cfthrow type="IncompleteBody" />
    </cfif>       
 </cffunction>
 

Introduction

We love MXUnit at work and at Mach-II to unit test our components and to do integration testing.  In Mach-II Simplicity (1.8), a big feature was our form and view custom tag libraries.  These features made developing the UI (view) layer of your application easier and less prone to error.  Why would you write this kind of form with manual data binding:

 <form method="post" encType="multipart/form-data" action="#BuildUrl('processUser')#">
         <h4>First Name</h4>
         <p><input id="firstName" value="#event.getArg('user').getFirstName()#" type="text" name="firstName"/></p>
         <h4>Last Name</h4>
         <p><input id="lastName" value="#event.getArg('user').getLastName()#" type="text" name="lastName"/></p>
         <p><input type="submit" value="Save Changes" /></p>
 </form>
 

When you could just write this and have auto binding:

 <cfimport prefix="form" taglib="/MachII/customtags/form" />
 <form:form actionEvent="processUser" bind="user">
         <h4>First Name</h4>
         <p><form:input path="firstName" /></p>
         <h4>Last Name</h4>
         <p><form:input path="lastName" /></p>
         <p><form:button value="Save Changes" /></p>
 </form:form>
 

Our First Pass Testing Solution and Failures

What this brings up is that a lot of complex logic is now inside of custom tags*.  How do you test custom tags?  For the most part, a lot of the logic in custom tags should be about output and not data manipulation.  MXUnit makes it easy to compare data if the results are simple values, structs, arrays, queries, etc.  However, the output from a custom tag is not just a simple string like "abc123" but more a complex string with nesting of tags and relationships between tags (for example a "select" and "option").

When we first started down this path of testing our custom tag libraries, we started by doing straight up text comparisons:

 <form:form actionEvent="something" bind="${event.user}">
             <cfsavecontent variable="output"><form:input path="firstName" /></cfsavecontent>
 </form:form>
 <cfset assertTrue(output EQ '<input id="firstName" value="#event.getArg('user').getFirstName()#" type="text" name="firstName"/>') />
 

This was simple but lead to an easy break down down the line.  There were two sticking points:

1) Our custom tag library has a "tag writer" relies a lot on looping over a struct of tag attributes .  As we all know in CFML, we cannot rely on the order of iteration of a struct.  So while assertion works on OpendBD it sometime failed on ACF8 because we were relying on the custom tag to ouput the tag attributes in the same order as our assertion string.  In all reality, the browser does not care about the order of the tag attributes and neither should our unit test.  The flexibility of the unit test was strongly coupled to string as a whole; not the individual parts.

2) It is hard to test relationships such as <select> and <option> tags in straigh string comparison.

2) Maintaining the unit tests becomes painful because of the first and second point.

These limitations were all deal breaker after just a week of trying to get tests to run all the time.  So on to find another solution that is less coupled to the straight string comparisons.

Our Second Pass Testing Solution and Failures

Ok, let's test individual parts like the value of an attribute using RegEx or Find() built-in functions:

 <form:form actionEvent="something" bind="${event.user}">
             <cfsavecontent variable="output"><form:input path="firstName" /></cfsavecontent>
 </form:form>
 <cfset assertTrue(Find("value="farrell"', output)) />
 <!--- More assertions --->
 

This works, but it is still extremely clumsy having to check for each attribute and we still cannot check the parent child relationships of tags like <select> and <option>.

Our Third Pass Testing Solution and Ultimate Successful Approach

How do you solve this predicament? We "sort of" solved problem #1, but #2 and #3 are still unsolved in my book.  Let's think about what the custom tag is outputting.  Hmm...our custom tag library output XHTML compliant code and there are many tools available to use to leverage XML .  So for all of you who think XML is bad, wrong and decitful -- it's time to eat your words. Luckily for us, MXUnit has a built-in assertion called assertXPath() that fits this use case perfect.

I know you're tired of me jabbering about how we got here so you'll want to see some code right?  Bare in mind that the Mach-II custom tags do some interaction with what is happening in a Mach-II request so we had fun setting up a fake request so the object required by the tag are in memory.  For the sake of brevity, I'm going to leave that setup code out of my examples however you can always see them in the Mach-II SVN repository (the joys of open source) if you want to learn more.

Let's look at testing a simple text input:

 <cffunction name="testInput" access="public" returntype="void" output="false"
     hint="Test basic 'input' tag.">
 
     <cfset var output = "" />
     <cfset var xml = "" />
     <cfset var node = "" />
     <cfset var bean = CreateObject("component", "MachII.tests.dummy.User").init() />
     <cfset var event = variables.appManager.getRequestManager().getRequestHandler().getEventContext().getCurrentEvent() />
 
     <!--- Add data to the the bean and set to the event so we can do binding --->
     <cfset bean.setFavoriteColor("red") />
     <cfset bean.setLastName("Farrell") />
     <cfset event.setArg("user", bean) />
 
     <cfsavecontent variable="output">
         <root>
             <form:form actionEvent="something" bind="${event.user}">
                 <form:input path="favoriteColor" />
                 <form:input path="lastName" />
             </form:form>
         </root>
     </cfsavecontent>
 
     <cfset xml = XmlParse(output) />
     <cfset debug(output) />
 
     <cfset node = assertXPath('/root/form/input[@type="text" and @value="red" and @id="favoriteColor"]', xml) />
     <cfset node = assertXPath('/root/form/input[@type="text" and @value="Farrell" and @id="lastName"]', xml) />
 </cffunction>
 

All XML documents require a "root" node of some sort.  In HTML, it's the <html> tag so in our unit test we just used <root> so XMLParse() wouldn't choke on the code.  We also want to check that the "id" attribute and the "value" attributes are what is expected and we can easily do that in our XPath assertion string.

Ok, so that's a simple example.  What about something more complex?  Let's look at how we test our <form:radiogroup> tag.  This tag takes a collection (lists, struct, array, array of structs or queries) and turns them into a group of radio buttons based off a template:

 <cffunction name="testRadiogroupWithQueries" access="public" returntype="void" output="false"
     hint="Test basic 'radiogroup' tag.">
 
     <cfset var output = "" />
     <cfset var xml = "" />
     <cfset var node = "" />
     <cfset var bean = CreateObject("component", "MachII.tests.dummy.User").init() />
     <cfset var event = variables.appManager.getRequestManager().getRequestHandler().getEventContext().getCurrentEvent() />
     <cfset var colors = QueryNew("v,l") />
 
     <!--- Add data to the the bean and set to the event so we can do binding --->
     <cfset bean.setFavoriteColor("red") />
     <cfset event.setArg("user", bean) />
 
     <!--- Test with simple array --->
     <cfset QueryAddRow(colors) />
     <cfset QuerySetCell(colors, "v", "red") />
     <cfset QuerySetCell(colors, "l", "Big Red") />
     <cfset QueryAddRow(colors) />
     <cfset QuerySetCell(colors, "v", "green") />
     <cfset QuerySetCell(colors, "l", "Giant Green") />
     <cfset QueryAddRow(colors) />
     <cfset QuerySetCell(colors, "v", "brown") />
     <cfset QuerySetCell(colors, "l", "Bad Brown") />
 
     <cfsavecontent variable="output">
         <root>
             <form:form actionEvent="something" bind="${event.user}">
                 <form:radiogroup path="favoriteColor" items="#colors#" labelCol="l" valueCol="v">
                     <label for="${output.id}">${output.radio} <span>${output.label}</span></label>
                 </form:radiogroup>
             </form:form>
         </root>
     </cfsavecontent>
 
     <cfset xml = XmlParse(output) />
     <cfset debug(node) />
     <cfset debug(output) />
 
     <cfset node = assertXPath('/root/form/label/input[@type="radio" and @value="red" and @id="favoriteColor_red" and @checked="checked"]', xml) />
     <cfset node = assertXPath('/root/form/label/input[@type="radio" and @value="green" and @id="favoriteColor_green"]', xml) />
     <cfset node = assertXPath('/root/form/label/input[@type="radio" and @value="brown" and @id="favoriteColor_brown"]', xml) />
     <cfset node = assertXPath('/root/form/label[@for="favoriteColor_red"]/span', xml, "Big Red") />
     <cfset node = assertXPath('/root/form/label[@for="favoriteColor_green"]/span', xml, "Giant Green") />
     <cfset node = assertXPath('/root/form/label[@for="favoriteColor_brown"]/span', xml, "Bad Brown") />
 </cffunction>
 

As you can see, we setup some test data and pass that to the "items" attribute of the <form:radiogroup> custom tag.  The tag doesn't know which columns to use for the value or for the label so we indicate that.  Let's take a closer look at the template that is being used:

 <label for="${output.id}"><span>${output.label}</span> ${output.radio}</label>
 

This template is interated over (i.e. looped over) for each item in the query.  We use a simple placeholder syntax of ${} to indicate where the radio and label are outputted (other computed attributes like the "id" are also available).  Our assertations in this case not only test for tags heirarchy and tag attributes, but the inner text of tags.  In this case, we need to test that the value of "${output.label}" that is displayed is correct (not the actual <label> tag).  We wrapped a <span> around it so we can easily find it with our XPath assertion.  Also, when testing for the "${output.label}" we need to make sure we're grabbing the right one so the XPath searches that the <span> is inside of a <label> with the correct "for" attribute.

In Closing

Testing custom tags with MXUnit is easy if you figure out the right plan of attack and after three iterations to our testing strategy -- we found one that works.  I'd be happy to hear if people have suggestions on improving how custom tag output can be tested with MXUnit, however at this point I think this solution is rather slick and leverages XML/XPath without the need for any custom assertions to be written in MXUnit.

Now no code should go un-tested including custom tags.  This is especially true in something like Mach-II which is a community asset and having unit tests makes the software a better product.  So now go forth and unit test your custom tag libraries!

* Sidebar: For performance, we used straight up custom tags with a "UDF"-like function library instead of having custom tags call CFCs.  Our basic testing at the time showed that CFCs were 10-15 times slower than the custom tag with "UDF"-like function library (included via a cfinclude).

Working with HTTP time strings should be easier to CFML / ColdFusion,
but there is no built-in function that will create a CFML date/time from
a UTC HTTP time string. So here is the UDF that can help you work with
HTTP time string in native CFML date/time functions. I didn't check
cflib.org first, but I really couldn't check it out of professional
courtesy because I was writing this function for open source project and
I didn't want to deal with attribution / license stuff (yes, I'm lazy).

<cffunction name="createDatetimeFromHttpTimeString" access="public" returntype="date" output="false"
    hint="Creates an UTC datetime from an HTTP time string.">
    <cfargument name="httpTimeString" type="string" required="true"
        hint="An HTTP time string in the format of '11 Aug 2010 17:58:48 GMT'." />

    <cfset var rawArray = ListToArray(ListLast(arguments.httpTimeString, ","), " ") />
    <cfset var rawTimePart = ListToArray(rawArray[4], ":") />
    
    <cfreturn CreateDatetime(rawArray[3], DateFormat("#rawArray[2]#/1/2000", "m"), rawArray[1], rawTimePart[1], rawTimePart[2], rawTimePart[3]) />
</cffunction>

Enjoy!

As for the narrative of what happened to the demise of the committee, it isn't worth my time to comment on it.  It is what it was and I have nothing if any real interest to add to what has already been said by Adam, Matt and Sean.  My resignation letter clearly explains my resignation:

http://blog.maestropublishing.com/open-cfml-advisory-committee-resignation-lett

In his blog post, Adam alludes to some inside knowledge on my life and the demands on my time.  Adam has absolutely no understanding or knowledge of my daily life and demands. It is rather imprudent and extremely rude to make assumptions and presume some alternate agenda.  This is the issue I take with Adam's post.  Straight from my resignation letter: "it has become increasingly difficult for me to contribute sufficiently to the CFML specification process".  I spent a lot of time over a period of a couple months debating my resignation.  In the end, I felt I did not have the time to serve the CFML community in a manner that did justice to the committee as a CFML *community* representative.

Just wanted to quickly blog that Matt Woodward and I are presenting on OpenBD on Google App Engine tonight at the Mid-Michigan CFUG at 7pm ET (about 30 minutes from the time of this posting).

Where: http://breeze.msu.edu/mmcfuggoogle  (Enter as guest)

When: June 8th, 2010 - 7pm ET

Description:

If you want to take advantage of the power of cloud computing but want to focus on applications instead of server infrastructure, you owe it to yourself to check out Google App Engine. Google App Engine lets you deploy applications to Google's infrastructure with the push of a button, and the best part is that for many applications it's entirely free of cost.

In this presentation we'll discuss both the benefits and downsides of living in the cloud, outline how Google App Engine differs from other cloud solutions, and demonstrate how to build and deploy a simple CFML application to Google App Engine using Open BlueDragon, which is the only CFML engine compatible with Google App Engine.

If you're interested in running your CFML applications in the cloud come get in on the ground floor, because with a few simple tips and tricks, it's all clear skies.