I linked Kenneth to a post that I wrote a year ago about combining 2 forms into a single view file. That approach works well for certain scenarios, but I’ve since changed my mind on my general preference for DRYing up forms.

How the previous approach affects workflow

Really, what’s caused my change of heart is driven by how my mind works when I’m maintaining an application. It’s important to constantly be thinking about this so we can make the boring stuff (maintenance) more efficient so we can spend more time on the fun stuff (innovation! creating new things!).

When I’m maintaining my Wheels application, I am sometimes in “view mode” or “data mode.” That will change the perspective on how I’m thinking about and approaching my application. If I’m in “view mode,” I’ll often start digging around in the files in the views folder without any regard for the CFCs stored in the controllers or models folders.

So if I want to change what happens on the form at views/users/add.cfm, that’s what I’m going to look for. Personally, I find that it’s annoying if I don’t find that particular view template and need to open the controller file to figure out what’s going on.

New approach: partials

Now I usually create partials to represent the pieces of code that need to be represented across several view templates. As you’ll see, this eliminates a lot of unneeded logic in the parent view templates as well as removing the need to set up so many variables in the controller actions.

Here is the new views/users/add.cfm with a partial call:

<cfparam name="user">
 
<cfoutput>
 
<h1>Create a New User</h1>
 
<cfif flashKeyExists("success")>
    <p class="success">#flash("success")#</p>
</cfif>
 
#startFormTag(action="create")#
 
#includePartial(user)#
<div>
    #submitTag(value="Create")#
</div>
 
#endFormTag()#
 
</cfoutput>

And now that I’m passing the user object to includePartial(), Wheels will auto-include the partial at views/users/_user.cfm:

<cfparam name="user">
 
<cfoutput>
 
#textField(objectName="user", property="name", label="Name")#
#textField(objectName="user", property="email", label="Email")#
#passwordField(objectName="user", property="password", label="Password")#
 
</cfoutput>

This is a lot simpler than what I had morphed the view template into in my original refactoring. There were way too many parameters, abstractions, and pieces of logic to unpack each time I revisited the template. Yuck!

So now I can change the template at views/users/edit.cfm to also include the partial and proudly display the other elements that make it unique in its own separate template (which includes a different <h1>, form action, button label, and the need to also provide a hidden field for id):

<cfparam name="user">
 
<cfoutput>
 
<h1>Edit User</h1>
 
<cfif flashKeyExists("success")>
    <p class="success">#flash("success")#</p>
</cfif>
 
#startFormTag(action="update")#
 
#includePartial(user)#
<div>
    #hiddenField(objectName="user", property="id")#
    #submitTag()#
</div>
 
#endFormTag()#
 
</cfoutput>

What does the controller code look like then? Well, now it’s back to the simplicity from the original tutorial:

<cffunction name="add">
    <cfset user = model("user").new()>
</cffunction>
 
<cffunction name="edit">
    <cfset user = model("user").findByKey(params.key)>
</cffunction>

Hooray for simplicity!

Experience is the best teacher

Sometimes you don’t really know how to handle some of these scenarios until you’ve played around with them a little. My first approach (the one I’m criticizing in this tutorial) is certainly a valid one and may make sense in certain scenarios, perhaps outside the context of forms.

I encourage you to try different approaches and share them with others so we can keep an open discussion about best practices. It takes a little humility to openly admit that I went down the wrong path earlier, but I hope that you will find some value in this discussion.

Pretty slick and very unobtrusive, and it keeps target="_blank" out of your markup, which is arguably a behavioral and not structural thing anyway. Plus it’s one step closer to killing target="_blank".

My slight modification: being a tad more user friendly

Here’s my version of the code:

$("a[href*=.pdf]").click(function(){
	window.open(this.href, "", "toolbar=0");
	return false;
});

I basically took what he did and added toolbar=0 to the arguments for window.open().

Why? Jakob Nielsen’s guidelines for opening PDFs in a new window call for removing browser chrome like the Back button. Why? Browser navigation doesn’t fit the paradigm for PDF document navigation. And Neilsen has watched thousands of users fumble around with the Web, while the rest of us have not.

In my layouts, I can reduce this logic:

<cfoutput>
 
<!--- Display error message from the Flash --->
<cfif flashKeyExists("error")>
	<div class="error-message">
		#flash("error")#
	</div>
</cfif>
 
<!--- Display success message from the Flash --->
<cfif flashKeyExists("success")>
	<div class="success-message">
		#flash("success")#
	</div>
</cfif>
 
</cfoutput>

To this line of code:

<cfoutput>
	#flashMessages()#
</cfoutput>

This takes care of 80% of your potential usage of the Flash in Wheels, and it reduces the logic to a single function call. Win!

In a nutshell, automatic validations remove the need for you to call simple validation functions like validatesPresenceOf(), validatesLengthOf(), and validatesNumericalityOf() in your models. Wheels will introspect your database fields for signals like NOT NULL, data types, and maximum lengths. When you call save(), create(), or update(), Wheels will run the validations for you based on this information (unless you specify otherwise).

If the database is already storing this information about your data, why not leverage it without writing any more code? Very clever stuff.

Here are the beginnings of my experimentation with the new feature. Feel free to follow along and see what’s coming up in the next version. There will be more.

So what was the error? It involved ExpandPath(). Fortunately, Dave Shuck’s blog saved the day for me. Evidently "/config/coldfishconfig.xml" means something different on Linux than "./config/coldfishconfig.xml". It was really strange what the first string translated to on my server. It was some weird path involving "shared://".

Go figure.

How the hell did any of us ever get by before Google got really good and everyone blogged about their solutions to problems?

Technorati Tags: cfwheels, coldfish, coldfish on wheels, ColdFusion, coldfusion on wheels, dave shuck, expandpath, linux, plugin, plugins