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

Take this, for example:

class PostsController < ApplicationController
    before_filter :find_post, :only => [:show, :edit, :update, :destroy]
 
    def show
        # ...
    end
 
    def edit
        # ...
    end
 
    def update
        # ...
    end
 
    def destroy
        # ...
    end
 
    private
 
    def find_post
        @post = Post.find(params[:id])
    end
end

Using the private keyword, the interpreter knows that all methods defined in the section afterward are private. It’s a pretty clean way of demarcating different blocks of code that have different roles.

While we have no such set of keywords for CFML except at the function level, why not use comments to do similar structuring of your CFCs?

<cfcomponent extends="Controller">
 
    <!------------------------------------->
    <!--- Public --->
 
    <cffunction name="init">
        <cfset filters(through="findPost, only="show,edit,update,destroy")>
    </cffunction>
 
    <cffunction name="show">
        <!--- ... --->
    </cffunction>
 
    <cffunction name="edit">
        <!--- ... --->
    </cffunction>
 
    <cffunction name="update">
        <!--- ... --->
    </cffunction>
 
    <cffunction name="destroy">
        <!--- ... --->
    </cffunction>
 
    <!------------------------------------->
    <!--- Private --->
 
    <cffunction name="findPost" access="private">
        <cfset post = model("post").findByKey(params.key)>
    </cffunction>
 
</cfcomponent>

A perfect translation? No. But an idea on how to use some simple comments to make your life easier when maintaining your code in the future.

I’ve taken it a step farther and also have been creating “Filters” sections for filters, just before “Private” methods.

Technorati Tags: cfml, cfwheels, ColdFusion, coldfusion on wheels, Programming, rails, ror, ruby, rubyonrails, web development

Unfortunately, the CFScript part of ColdFusion isn’t quite where it needs to be yet.

Don’t get me wrong: CFScript is much improved over where it was in previous versions of ColdFusion. And I don’t get angry when I experiment with a feature and it doesn’t work out, but I also try my hardest to know when to back off and undo any damage before it goes too far.

What didn’t work

As it turns out, doing custom database queries in CFScript is very cumbersome. It starts feeling a little too much like PHP. Maybe even worse!

Consider this beautiful, expressive simplicity that we all love about CFML:

<cfquery datasource="#get('dataSourceName')#" name="local.apps">
    SELECT DISTINCT
        A.*
    FROM
        apps A
        JOIN appgroupmemberships G
            ON A.id = G.appid
    WHERE
        G.usergroupid IN (#local.groupIds#)
        AND deletedat IS NULL
</cfquery>

And replace it with this garbage:

local.queryService = new Query(datasource=get('dataSourceName'));
local.queryService.setSql("
    SELECT DISTINCT
        A.*
    FROM
        apps A
        JOIN appgroupmemberships G
            ON A.id = G.appid
        WHERE
            G.usergroupid IN (#local.groupIds#)
            AND deletedat IS NULL
");
local.apps = local.queryService.Execute().GetResult();

The last line is the part that really gets me. What is this, Java?

Also, it gets much worse when you need to cut in and out of the SQL string that you’re building in order to add in if logic, loops, calls to AddParam(), etc.

The other big annoyance to me is CFScript’s lack of coverage for many of the other data communication tags. It hurts to not have equal functionality available for cffeed, cfldap, etc. I need to call more than just databases in my models and controllers.

Realization: I need to support Railo too

I need to work on adding support for Railo, which doesn’t yet support full script-based components anyway. So it was probably in my best interest to take some time to convert my components back to CFML again.

Perhaps our paths shall cross again some day, CFScript. Until then, I bid you adieu.

Technorati Tags: adobe, ccm, cfml, cfscript, chris peters, clear crystal media, ColdFusion, oop, polymorphism, railo

The strategy

What I really wanted was a function that I could call whenever a given view’s record could not be found.

In my example case, I wanted to handle user IDs in the People Directory that represent records that don’t exist. I had ended up removing user 31 (and a few others), so I wanted to display a helpful 404 error message every time http://cfwheels.org/user/profile/31 was accessed.

404 error page

So the first step was to create the 404 page itself, which I stored at views/main/error404.cfm.

<cfsetting enablecfoutputonly="true">
 
<cfset layout.title = "Page Not Found | ColdFusion on Wheels">
<cfset layout.header1 = "Page Not Found">
<cfset layout.breadcrumbs = ["Page Not Found"]>
 
<!--- 404 error --->
<cfheader statuscode="404" statustext="Not Found">
 
<cfoutput>
 
<p>
    We're sorry. We couldn't find the page that you're looking for. It has either been removed, or perhaps
    you are accessing an inaccurate <abbr title="Uniform Resource Locator">URL</abbr>.
</p>
 
<h2><label for="search-query-404">Search</label></h2>
#startFormTag(controller="search", id="cse-search-box", method="get")#
    <div>
        <input type="hidden" name="cx" value="005724978648843866544:jpej79qhz14" />
        <input type="hidden" name="cof" value="FORID:10" />
        <input type="hidden" name="ie" value="UTF-8" />
        <input id="search-query-404" type="text" name="q" />
        <input type="submit" name="sa" value="Search" />
    </div>
#endFormTag()#
 
<h2>Start from the Home Page</h2>
<p><strong>#linkTo(text="ColdFusion on Wheels Home &raquo;", route="home")#</strong></p>
 
</cfoutput>
 
<cfsetting enablecfoutputonly="false">

The real meat is the fact that I put the <cfheader> 404 reference in the view file. I look at anything that’s sent to the browser as a job for the view to handle, so that’s why I put the call there instead of in the controller file. In fact, because the page is fairly “dumb,” I didn’t put anything in the Main controller.

Rendering helper

I also put a quick render404() function in the base controller at controllers/Controller.cfc so that I wouldn’t need to manually call renderPage(controller="main", action="error404") every time that I wanted to reference this new view. Your preference may be to not do this, but I’ll leave that up to you.

<cffunction name="render404" hint="Renders a 404 error page.">
 
    <cfset renderPage(controller="main", action="error404")>
 
</cffunction>

Handling 404 errors in the controller

The last step involved actually using this functionality in the case that an invalid record ID was passed in the URL. So the user/profile action now looks like this:

 <cffunction name="profile" hint="Displays user profile.">
 
    <cfset user = model("customer").findByKey(params.key)>
    <cfset loggedInUser = getLoggedInCustomer()>
    <!--- If profile found, show it --->
    <cfif IsObject(user)>
        <cfset sites = user.sites(where="isApproved=1")>
        <cfset plugins = user.plugins(where="isApproved=1")>
    <!--- 404 error if not found --->
    <cfelse>
        <cfset render404()>
    </cfif>
 
</cffunction>

Fairly simple stuff. When loading the user object, I check to see if an object was returned. If not, then show the 404 page. Pretty reusable, and it only requires an additional if/else block in the controller to decide what to do.

Plus the file at events/onmissingtemplate.cfm can just use <cfhttp> to phone http://cfwheels.org/main/error404 in order to display the exact same error message during a more generic “template not found” scenario.

Besides identifying other places in the application to call render404(), that’s pretty much it.

Technorati Tags: 404 errors, cfml, cfwheels, ColdFusion, coldfusion on wheels, error handling, framework, frameworks, mvc, web development