The first function takes an array of PDF documents and merges them into one. This was handy when different pages for a report had different styling requirements (such a full background colouring bleeding across the margins)

The second function stamps a pdf document over another pdf document at certain position. I needed this for a document that had a table dynamically generated that spanned multiple pages and I wanted the footer to not overlap the table content (I could not figure out how to use a css based solution because of the margins).

Anyway maybe somebody else will find these handy.

I also tidied up a few things in the code for rendering the CFCs and fixed an issue with the VarScopeChecker not being picked up by MXUnit.

As always feedback is most welcome!

The snippet below shows my new session checking code.

The trick is to intercept the call when you do your session checking at the back end. Let's say you have a fuseaction called login.login (see below and yes this is fusebox 3 :S) where you display the login form when a user is not logged in, this is where I inserted the check for an XHR request, by looking at the http headers sent along with the request. The key here is a new header attribute passed in with Prototype "X-Requested-With". If this attribute exists then I know it's an XHR request and I can create a custom JSON header with an error struct that holds a key called session with a value of timeout. All I then need to do is encode the struct as JSON and pass that encoded struct back to the browser.

Now let's jump back to the JavaScript code and take a look at the onComplete function again:

If there's a JSON object and it has a key of session then I call my setSessionExpired function which redirects the users. Now the json session key only exists in these situations since the call normally just passes back the result of the call.

1. cfUnit is now supported
2. A fix for cfmx 6.1 and recursive directory lookups
3. The code can now handle missing tearDown methods in existing test cfcs.

I have also tried to simplify the config.xml file a little and here's what the default looks like:

A concrete example usually works best, so:

appName : This now refers to a cf mapping in the administrator for my project, in this case art, however if you are using a package approach (with say a value of "com.domain"), then this value would simply be appended to the packageRoot (e.g. com.domain.art)

appPath : This is now the full path to the application, e.g. on my local machine /Users/gregstewart/Sites/Client X sites/Fusebox/ART2/

packageRoot : Hasn't changed

saveTestFilesTo : Hasn't changed

unitTestFramework : Now supports cfUnit.

coldSpring : Something working on, i.e. use ColdSpring to generate mock objects. Could be ages before it sees the light of day, if my past track record is anything to go by.

Thoughts and suggestions are still most welcome!

• Squidhead and CFUnit
• Stub Generator for CFCs, Unit Tests, and More

Both projects do a hell of a lot more than just create test objects though. Definitely worth checking out.

Feel free to comment here, use the forums or even log an issue with the tracker!

• Basic install instructions
• Links for feedback, issues and suggestions

Installation

The simplest way to install stubbie is to just place it in your webroot, alternatively you can just create a mapping called /stubbie and point it to your install folder.

Usage

Using stubbie requires 2 steps the first is editing config.xml and the second is calling the component.

Step 1
Open up the config.xml file and edit it the following settings

Step 2

Place the following code anywhere you wish to invoke stubbie from: