The amazing adventures of Doug Hughes

Archive for January, 2007

Want Some Tickets to the Super Bowl?

A year or so ago I helped start a new site, The site is new way to buy vacation travel to enjoy the Sunshine State, its beaches, resorts and attractions. You can either bid on packages (starting at 80% of retail) or buy them directly from the supplier partner.

Florida Vacation Auctions has established a partnership with VisitFlorida, the state’s official tourism corporation. Through this partnership, a pair of tickets to Superbowl XLI (which just so happens to be in South Florida this year) has been made available for Auction. All of the proceeds will be donated to NFL Charities.

The tickets are located in Level 100, Section 156, Row 14, Seats 23 & 24. This is in row 14 of the bottom deck!

Bidding started at $280 and has gone of up from there. But there’s nothing stopping you from placing your bid now!

This might be a bit much to ask, but, because the proceeds are being donated to charity, it would be fantastic if those of you with blogs could help spread the word about this auction!

And, even if you don’t go to the Superbowl, you should still check out the site. There are some tremendous values available now and more published every week.

Reactor Mailing List Update

For a long time now, the reactor mailing list has worked on two email addresses, and Because Im moving from my current mail server to using Gtalk for Domains Im going to have to disable The mailing list should continue to work as it always has from

Extending Model-Glue via ColdSpring

Every day I use ColdSpring I fall more and more in love with it. I am absolutely enraptured with the fact that changing how an application behaves is as simple as changing configuration. Consider this example, which I did yesterday:

I’ve been experimenting with Model-Glue Unity’s generic read and commit messages. In the past I considered them to be handy, but only under certain circumstances. They do have some limitations I don’t like. For instance, if I use soft deletes to flag a record in my database as deleted I don’t want the generic delete to actually try to delete that record. (Besides, what if that record had foreign key constraints that prevented it from being deleted? Ugh.)

Also, when using generic lists, all the records would show up even when they were soft deleted. The easy solution for that was simple enough, simply pass deleted=1 through your URL and add that as a criteria for your list. The thing is, not only does that make the URL that much longer and uglier, users with half a wit could easily view deleted items (but never both deleted and undeleted).

What did I do? Well, I dug into Model-Glues core configuration file, located at /ModelGlue/unity/config/Configuration.xml, which just so happens to be a ColdSpring bean definition file. It didn’t take long to find the block of XML that configured the Reactor ORM adaptor. (I just hit Alt-F and searched for Reactor.) This turned up this block of code:

<!-- Reactor adapter/service -->
<bean id="ormAdapter.Reactor" class="ModelGlue.unity.orm.ReactorAdapter">
    <constructor-arg name="framework"><ref bean="ModelGlue" /></constructor-arg>

Now, let’s stop and think here for a minute. How does Model-Glue use this adaptor? Well, in a nutshell, it asks ColdSpring for it. ColdSpring configures the specified bean and returns it. Once Model-Glue has its Reactor adaptor it simply calls methods on the adaptor’s public interface.

Specifically, Model-Glue expects an object that implements the same interface as its AbstractORMAdapter. That means we could completely implement the interface defined in the AbstractORMAdaptor or that we could extend the ReactorAdaptor and override a few functions.

For those who don’t know, your ColdSpring.xml file in your Model-Glue application actually overrides settings in the core configuration. This means that to override the configuration all I needed to do was to add an equivalent block into my application’s ColdSpring.xml file.

So, I created my own ReactorAdaptor which looks like this:

<cfcomponent extends="ModelGlue.unity.orm.ReactorAdapter" hint="I am a custom implementation of the MG:U ReactorAdaptor">
    <cffunction access="public" name="delete" output="false" returntype="any">
        <cfargument name="table" required="true" type="string"/>
        <cfargument name="primaryKeys" required="true" type="struct"/>
        <cfset record=read(arguments.table, arguments.primaryKeys) var/>
        <cfset record.setDeleted(1)/>
    <cffunction access="public" name="list" output="false" returntype="any">
        <cfargument name="table" required="true" type="string"/>
        <cfargument name="criteria" required="false" type="struct"/>
        <cfargument name="orderColumn" required="false" type="string"/>
        <cfargument default="true" name="orderAscending" required="false" type="boolean"/>
        <cfargument name="gatewayMethod" required="false" type="string"/>
        <cfargument name="gatewayBean" required="false" type="string"/>
        <cfset arguments.criteria.deleted=0/>
        <cfreturn super.list(argumentCollection=arguments)/>

Note that this extends the standard ReactorAdaptor and overrides the delete and list methods to implement the functionality I wanted.

Next I updated my application’s ColdSpring.xml configuration and added this:

<bean id="ormAdapter" class="model.orm.ReactorAdaptor">
    <constructor-arg name="framework"><ref bean="ModelGlue" /></constructor-arg>

Now, as soon as I reloaded my application I was able to use generic list and delete messages with soft deletes.

It doesn’t stop here though. I also extended the core ormController to take care of a few chores automagically for me. For example, I disassemble Reactor Records down to simple event variables (which makes interfacing them with non-scaffolded forms a lot easier) and setup a system to enable multiple generic deletes easily.

How cool is that? Thank you to Joe Rinehart for having this insight about a year before me! Thanks also to the ColdSpring team for making this possible!

Tag Cloud