Monthly Archives: July 2007

Using Custom Plugins and Coldbox

After some head rattle and some wise words from Team Coldbox, they have explained to me that Plugins in Coldbox serve there purpose of ‘enhancing and creating reusability’.

But will soon be able to plug in at certain ‘execution points’. Coldbox and AOP in the next release. Nice!

You may think Coldbox already has a few execution point with the PreHandler/PostHandler methods within the handlers(controller) themselves.
But they are limited to specific handlers.

Coldbox also allows you to designate code at the start and finish of every request using the OnRequestStartHandler RequestEndHandler event defined in your config.xml.
And on a broader level there’s an ApplicationStartHandler available in there to.

Depending on the impact of the plugin placement is for you to decide.

But for an example let’s use the idea of securing our apps. And we have Accounts withe Roles attached to them. The Roles are also tied to individual events and entire handlers depending on access.

So what should you do?

Well, if you want to ‘follow standards’, create a plugin and call it with the OnRequestStartHandler. ‘Don’t throw methods anywhere, make sure they have an identity.’ Keeping in mind encapsilation and trying to avoid dependecy. It’s those OO fundamentals again.

But sometimes its easy to slip.

For example, why not just throw an method into the securityService and call that from the PreHandler in those handlers that have events that need to be secured?

Well for starters, what if the user didn’t have access to run the event, or better yet any of the events in that handler. You could have avoided even calling upon this handler. If you had checked at the beginning of the request using the OnRequestStartHandler you could have deciphered that there was no need to make a call to that handler.

Theres another problem when you check from within the handler. You have created a dependency. That handler now needs that securityService to be there. Not good. If you had to, at least use use a plugin here. The handlers have native access to those with Coldbox. But remember, you could have stopped yourself from even getting this far.

Now let’s tighten things up a bit. Forget about making all these scattered calls to the securityService. Realize the reusability for a security module, and that its nature is that of a ‘plugin’. The purpose is to handle calls to the securityService at some point in the Request Life Cycle, call it an Interceptor. Create yourself a securityInterceptor plugin, and of course there’s a doc for writing a plugin at the

Use this to create a layer between the Coldbox framework and your custom securityService.
Your plugin will be generic enough to be shared with other Coldbox apps, and the app specific code will belong in the service.
So when a change comes along you’re only modifying your service layer.

** I am in the process of cleaning up my code examples for this. So check back in a few. **

Postgre Error: Relation does not exist

I’m working on an app that integrates with the Transfer ORM. The code runs on an MS SQL and MySQL database without a problem. However, when switching over to Postgre one table causes things to flop.

When it queries the table i get the error: relation “tableName” does not exist.

I look at the SQL involved and its a basic select. So I try select * tableName, and get the same error in the query window.

If I add double quotes around “tableName” it works fine.

That’s a solution but not an explanation for the problem.

Why is it, that for this tableName, I need the double quotes?

Well it can be one of two things…

The tableName is a reserved word in Postgre or when you created the table you used mixed cases (tableName) or upper case (TABLENAME). Had you created the table lower case (tablename) then you would have never seen this error. So if you are using an ORM that extends itself to Postgre be sure to create tables and column names in lower case.

ColdSpring, VMs, and Shared Folders

I am running ColdFusion on my Windows 2003 Server VM. I have my files on my local machine, available to my VM via a shared folder. Meaning, IIS and CF see it as .hostShared FoldersWebroot
When Coldspring is initialized it runs theshrinkFullRelativePath method in the DefaultXmlBeanFactory.cfc

If you are passing in an expanded path then Coldspring will thrown an error because of the rebuilding of the path and the ” before ‘.host’ gets stripped down to ‘/’ and is not a valid path.

Or, you are sending in a relative path and its just not found at all.

In the meantime modify this check before the return of the shrinkFullRelativePath method to:









If your’re not dealing with a VM but still want to use Relative Paths, only use the second if statement.

** This may only be good for people using ColdFusion 7 and Up. (Application root mapping support issues)

Installing and Configuring Subversion (SVN) on Mac OS X with MacPorts

This is a simple guide for a simple SVN server solution. I am installing Subversion with a MacPorts nice little auto-installer for public packages.

I started off by using MacPorts to search for the package with:

port search subversion

then installed the package with

sudo port install subversion

MacPorts installs all the required packages and the latest subversion release.

Subversion is now installed. Now let’s get the Server setup.

Create a folder where you will be storing all your Repository files. (/RepoHome)

Then to create a new repo from the shell run:

svnadmin create /RepoHome/NewRepoName

This next step is Optional. If you want to have user authentication, you need to go to the folder of the repo you want to add security to. In the /conf folder you will see 3 files. Open all 3 and the comments say it all.

Now, to start up our SVN server.

svnserve -d -r /RepoHome

(this loads it in daemon mode with a root path of /RepoHome)

If running a Firewall be sure ports 3690 and 80 are open.

To connect to the repo point your SVN client to:

svn://serverAddress/newRepoName

Install and Setup Subversion (SVN) Repository in Windows

I just posted about doing this on a Mac. After I did that, I realized I need to install this on my server and start reading up on the security settings. But anyway, very similar to the Mac install, this is even easier, actually.

Grab the latest windows installer package from the Subversion Tigris Site.

Run the installer with the defaults.

Create a folder to house the Repositories. (/RepoHome)

Bring up a command promt and run: (startuncmd)

svnadmin create /RepoHome/NewRepoName

To setup user authentication and permissions go to the /RepoHome/NewRepoName/conf folder and open the 3 files in there. The comments in the files explain it all.

To start the SVN daemon run:

svnserve -d -r /RepoHome

(this starts it with a root of /RepoHome)

Ports used: 3690 and 80

To connect to the repo point your SVN client to:

svn://serverAddress/newRepoName

Using a Decorator with Transfer

Transfer was built to allow you to extend its capabilities. Using the Decorator Pattern you can overlay/overwrite methods of a TransferObject and add methods of your own. Remember its a Decorator to the Transfer Object(the Bean). So the methods you add should be relative to the Bean. To add DB or other external functions, there are other ways.

Here’s how you setup the Decorator.

1. Add the decorator attribute to the object element in your Transfer Config XML file.


2. Create your Decorator CFC and extend the Transfer Decorator Object.





You also have access to getTransfer() when you extend the Transfer Decorator Object.

That’s it. Re-init Transfer and your Decorator methods will now be available from your Transfer Objects.

To take it a step further, I have created a Base Decorator to share methods accross Decorators. But that’s another Blog.

Extending a Base Decorator with Transfer

So you have a few methods you want to include in every Transfer Object, and you don’t want mess with mix-ins, and copy/paste isn’t an option. You want to extend it but its already extending the transfer.com.TransferDecorator. So what can you do?

1. Create your Base Decorator CFC, and extend the transfer.com.TransferDecorator.












2. Now change the ‘extends’ in the object decorator to extend the Base Decorator CFC





Now you’ll have the baseDecorator and the accountDecorator methods available to you from your TransferObject.

Wait…What if you only need to extend the baseDecorator to your TransferObject and don’t forsee a need for an accountDecorator? Dont create an empty accountDecorator just to extend the baseDecorator.

Change the value of the decorator attriute in the Transfer Config XML to the path of your baseDecorator.