<!--- `views/customers/new.cfm` --->
<cfparam name="customer">
<cfparam name="countries" type="query">
<cfparam name="states" type="query">
 
<cfoutput>
 
#startFormTag(route="customer")#
    #textField(objectName="customer", property="name")#
    #textField(objectName="customer", property="email")#
    #select(objectName="customer", property="countryId", options=countries)#
    #select(objectName="customer", property="stateId", options=states)#
#endFormTag()#
 
</cfoutput>

There are many ways that you can load the data that this view template is requiring, each with their pros and cons. I’ll cover 3 different approaches.

Approach #1: Use before filters to stay DRY

One way to solve this problem in the controller is to run before filters on the new, create, edit, and update actions:

// `controllers/Customers.cfc`
component extends="Controller" {
 
    function init() {
        verifies(only="edit,update,show", params="key", paramsTypes="integer");
        verifies(only="create,update, params="customer");
        filters(only="new,create,edit,update", through="$setStates,$setCountries");
    }
 
    function new() {
        customer = model("customer").new();
    }
 
    function create() {
        customer = model("customer").new(params.customer);
        if (customer.save()) {
            redirectTo(route="customer", key=customer.key(), success="...");
        }
        else {
            flashInsert(error="...");
            renderPage(action="new");
        }
    }
 
    function edit() {
        customer = model("customer").findByKey(params.key);
    }
 
    function update() {
        customer = model("customer").findByKey(params.key);
        if (customer.update(params.customer)) {
            redirectTo(route="customer", key=customer.key(), success="...");
        }
        else {
            flashInsert(error="...");
            renderPage(action="edit");
        }
    }
 
    function show() {
        customer = model("customer").findByKey(params.key);
    }
 
    private function $setStates() {
        states = model("state").findAll(order="name");
    }
 
    private function $setCountries() {
        countries = model("countries").findAll(order="name");
    }
}

Notice the call to filters() in init() to load the $setStates() and $setCountries() private filter methods.

Yes, this works. But one problem is that you only need to load states and countries if the form needs to be shown with errors. On create and update, those queries may not even need to be run, but they’re running anyway. Why hit the database if you don’t need to?

Depending on your caching strategy, this may not matter if you are caching the findAll() calls. But let’s say that you are running at least one of those queries in real time. How do you avoid running them if you don’t need them?

Approach #2: Limiting the use of filters and calling them manually in create and update

An approach that alleviates that problem is to limit the before filters to new and edit and only run them when needed in create and update:

// `controllers/Customers.cfc`
component extends="Controller" {
 
    function init() {
        verifies(only="edit,update,show", params="key", paramsTypes="integer");
        verifies(only="create,update, params="customer");
        filters(only="new,edit", through="$setStates,$setCountries");
    }
 
    function new() {
        customer = model("customer").new();
    }
 
    function create() {
        customer = model("customer").new(params.customer);
        if (customer.save()) {
            redirectTo(route="customer", key=customer.key(), success="...");
        }
        else {
            $setStates();
            $setCountries();
            flashInsert(error="...");
            renderPage(action="new");
        }
    }
 
    function edit() {
        customer = model("customer").findByKey(params.key);
    }
 
    function update() {
        customer = model("customer").findByKey(params.key);
        if (customer.update(params.customer)) {
            redirectTo(route="customer", key=customer.key(), success="...");
        }
        else {
            $setStates();
            $setCountries();
            flashInsert(error="...");
            renderPage(action="edit");
        }
    }
 
    function show() {
        customer = model("customer").findByKey(params.key);
    }
 
    private function $setStates() {
        states = model("state").findAll(order="name");
    }
 
    private function $setCountries() {
        countries = model("countries").findAll(order="name");
    }
}

Notice the modified call to filters() in init() and the manual calls to $setStates() and $setCountries() in the create and update actions.

This is better because now the states and countries are only being loaded when absolutely needed. This does make things slightly less DRY, but it’s not too bad of a trade-off.

Approach #3: Using Automatic Data Functions to Load Data for the Form

Yet another approach is to factor out the form into a partial and use what’s called an automatic data function to load the extra queries.

So the view template changes to this (which you may be doing anyway):

<!--- `views/customers/new.cfm` --->
<cfoutput>
 
#startFormTag(route="customer")#
    #includePartial("form")#
#endFormTag()#
 
</cfoutput>

And now you create a partial:

<!--- `views/customers/_form.cfm` --->
<cfparam name="customer">
<cfparam name="arguments.countries" type="query">
<cfparam name="arguments.states" type="query">
 
<cfoutput>
 
#textField(objectName="customer", property="name")#
#textField(objectName="customer", property="email")#
#select(objectName="customer", property="countryId", options=arguments.countries)#
#select(objectName="customer", property="stateId", options=arguments.states)#
 
</cfoutput>

You may now notice that the countries and states variables are now being referenced in the arguments scope. That’s because we’re going to load them from an automatic data function.

The controller should now look like this:

// `controllers/Customers.cfc`
component extends="Controller" {
 
    function init() {
        verifies(only="edit,update,show", params="key", paramsTypes="integer");
        verifies(only="create,update, params="customer");
    }
 
    function new() {
        customer = model("customer").new();
    }
 
    function create() {
        customer = model("customer").new(params.customer);
        if (customer.save()) {
            redirectTo(route="customer", key=customer.key(), success="...");
        }
        else {
            flashInsert(error="...");
            renderPage(action="new");
        }
    }
 
    function edit() {
        customer = model("customer").findByKey(params.key);
    }
 
    function update() {
        customer = model("customer").findByKey(params.key);
        if (customer.update(params.customer)) {
            redirectTo(route="customer", key=customer.key(), success="...");
        }
        else {
            flashInsert(error="...");
            renderPage(action="edit");
        }
    }
 
    function show() {
        customer = model("customer").findByKey(params.key);
    }
 
    private struct function form() {
        local.data.states = model("state").findAll(order="name");
        local.data.countries = model("countries").findAll(order="name");
        return local.data;
    }
}

The true points of interest in this example are the init() and form(). We’re now no longer running before filters in init() to load the states and countries.

Also, there is a new private method named form() that acts as an automatic data function. Every time you call a partial, Wheels checks for a method in your controller with the name of the partial, private access, and a return type of struct. If it finds that method, it’ll run it and merge the struct that it returns into the arguments scope in the view.

So form() is only being run when the form is shown via the call to #includePartial("form")#. And the data loading is still happening in the controller where it belongs.

I’ve only begun playing around with this method and so far have been enjoying the results. I am slightly torn because I like the “self-documenting” nature of declaring filters in init(), but that method does have the caveat that I mentioned before. The automatic data function solves this problem, but it does make the functionality a little less obvious. You need to remember the extra step of checking to see if there is a method in the controller with the same name as the partial when you run across one.

Has anyone else play with this method? If so, how has this worked out for you?

Here’s a little tip to keep anyone in your organization using Google Analytics from accidentally reloading your ColdFusion on Wheels application in the wrong environment.

Problem: people can see your reload URLs

You wouldn’t think that Google Analytics would have anything to do with this, but consider this scenario:

1. A non-technical teammate of yours runs some content reports in Google Analytics.
2. The teammate keeps seeing a URL appearing in the reports that looks something like this:
   /?reload=maintenance&password=123456.
3. They eventually say to themselves, “Hmm, I wonder what that does. I’m going to click it.”
4. You get an emergency call because your website is in maintenance mode all of a sudden, and you’re not sure why it happened.

Solution: Exclude URL Query Parameters setting

The solution is pretty simple. You just need to go into the Google Analytics settings area for each of your Wheels apps’ profiles and exclude the reload, password, and except URL paramaters from appearing in Google Analytics.

Your settings would look something like this:

Here’s how to get to the profile settings for your Wheels app:

1. Open the reports for each profile
2. Click the Gear icon in the upper right
3. Click the Profile Settings tab
4. Edit the Exclude URL Query Parameters field.

More information

• Edit Profile Settings article in Google Analytics Help
• Switching Environments chapter in ColdFusion on Wheels Reference Guide

Technorati Tags: analytics, ccm, cfwheels, chris peters, clear crystal media, ColdFusion, coldfusion on wheels, ColdFusion on Wheels, google analytics, polymorphism, security, web analytics

Form field [asset[file]] doesn’t exist or has no content

After a couple hours of beating my head against the wall, I realized that I didn’t set enctype="multipart/form-data" on the form tag.

Fortunately, this is a fairly simple fix using the Wheels startFormTag() form helper and its multipart argument:

#startFormTag(route="assets", action="create", multipart=true)#
...
#endFormTag()#

I’m sad to report that this isn’t the first time that this has happened to me, and it probably won’t be the last. I hope that my poor brain will remember the meaning of that error message the next time that I see it.

Technorati Tags: cffile, cfml, cfwheels, ColdFusion, coldfusion on wheels, error, errors, railo

I finally squashed the bug tonight in version 0.7 of the plugin. Be sure to download the new version if you’re planning on using the plugin in your application.

By the way, Russ has been a blogging machine lately. Be sure to check out his blog for some ColdFusion on Wheels goodness.

Technorati Tags: ccm, cfwheels, chris peters, clear crystal media, coldfish, ColdFusion, coldfusion framework, coldfusion on wheels, ColdFusion on Wheels, plugin, plugins, polymorphism, railo, web development

I’ve been working on a plan for migrating a Fusebox application to Wheels, and it’s been a pretty challenging task to think through it all. I don’t care what framework or platform you’re migrating to. It’s not easy. It’s much easier to start anew, but most of us do not have that leisure.

The good news is that Wheels gives you a few tools to help out:

• Object relational mapping allows you to trick Wheels into using a database structure that doesn’t quite meet Wheels’s expectations for conventions
• URL routing enables you to build sub-applications and then bubble them up to a single giant application (if that’s the path that you’ve chosen to take)
• Different methods of refactoring, inheritance, and plugin development give you the ability to start with messy code and make it cleaner and DRYer with each iteration—when you need it (and as you learn more about the Wheels framework)

To be quite frank, I’m not sure what all I can share in 45 minutes. But I hope whatever I present will get the ideas flowing and the conversation going.

Also, if you subscribe to my posts, I’ll share more of my experiences as I get deeper and deeper into this migration project. It involves moving a FoxPro database to SQL Server (which isn’t my responsibility, thank the Lord), translating it to match Wheels conventions, and building an application layer with some pretty convoluted business logic.

Isn’t that the way it always is?

Technorati Tags: application development, ccm, cfmeetup, cfwheels, chris peters, clear crystal media, ColdFusion, coldfusion on wheels, framework, frameworks, migrate, migration, migrations, polymorphism, presentation, presentations