How to Customize An Application

Today's been an interesting day for me.

I found myself rereading this old blog entry from Jason Delmore from last year. It was about why Adobe doesn't give ColdFusion away for free like PHP or Ruby, which of course people still debate today although there's not really any reason to debate it anymore with there now being three separate free CFML engines in various stages of development (Railo, Open BlueDragon and SmithProject) and an upcoming CFML language standard committee.

Whatever your opinion on the idea of standards or for that matter committees, you can't argue that 2008 was anything but an eventful year for the ColdFusion community. Some of the news is just caching up to us like the announcement of the beta for the new Bolt IDE for ColdFusion. The community spoke and Adobe listened. Announcements regarding the features of CF9/Centaur (such as Hibernate ORM) are of course similarly exciting. And then there have been all the wow events in the community like Railo announcing their becoming part of the JBoss project and becoming free/open-source and Kristen Schofield announcing the free educational licensing for ColdFusion and releasing the evangelism kit that finally arms us with some great information for evangelizing the platform, allowing you to "be your own Ben Forta" as she described in her Max presentation. :)

These are all great things for the ColdFusion community, they will be great things for the CF Open Source community generally and personally I know they will be great things for the onTap framework community specifically as we grow rapidly over the next year or two.

ColdFusion is a bit unusual in the way it does things. Although it's not without its challenges as is the case with any language, CF has often been the first in new areas. Notably, CF was the first server of its kind to connect the web to databases seamlessly and easily over ten years ago when Allaire released the very first version. The onTap framework today is in some ways following in that pioneering spirit and right now I'd like to show you a few specific features that make it truly unique in today's CF open source community.


What's On the Menu?

The office where I'm working currently, we have a lot of this

[&nbsp;<a ...>main</a>
<cfif xyz>&nbsp;|&nbsp;<a ...>users</a></cfif>
&nbsp;|&nbsp;<a ...>documents</a>&nbsp;]

I imagine a lot of you are already familiar with this sort of thing... Probably most of you don't think much of it, but this sort of thing can be problematic. Primarily what I'm talking about here is the brackets [ ] surrounding the menu and the pipes in between the menu items. This style of display has been pretty popular at a lot of the places I've worked, but then I've also seen a lot of cases where an item in the menu isn't displayed for one reason or another and you get || in the menu, i.e.

main |  | documents ]

Instead of

main | documents ]

Or sometimes an extra pipe on either end like this

main | documents  | ]

And I know a lot of people think "so what?" ... but the point here isn't that it ever happens. No amount of experience or education prevents us from making mistakes. The most brilliant programmers still create typos and contribute code containing seemingly simple mistakes, because whatever we might want to think about our abilities, we're still human. That's why I always cringe when I hear managers berate people for "not testing your code" -- but every manager I've ever met does it. People make mistakes and sometimes that means code going to production with a bug - PERIOD. Their being human doesn't require they be made to feel like crap. If the software going to production is too error prone it's almost always because the company doesn't have a good Quality Assurance (QA) team and/or continue to demand that changes be made at break-neck speeds and refuse to set reasonable deadlines. (In my experience most companies have *NO* QA team, and demand break-neck deadlines in addition, which is a whole other rant.)

No my point about this in particular is that display bugs of this variety are pretty common when the code is formed the way you see it up above. It's the same reason why I wouldn't want a hot-key for "delete" right next to a hot-key for "save". It's about taking simple steps to make some of these common mistakes less common. This is why the framework offers the features to support this:

<div tap:open="[" tap:close="]"

<a ...>main</a>
<cfif xyz>
<a ...>users</a>
<a ...>documents</a>

Now this code will produce basically the same menu above, however, it will also ensure that you don't accidentally leave any pipes in or out of conditional statements to produce that display bug up above. It also has some other advantages, for example it involves fewer keystrokes and no duplication (you only enter the pipe character once). And then there are the extended advantages that you can use a combination of the framework's native XSLT features and/or the native internationalization features to easily replace the pipes and brackets for special needs or for branding for clients who would prefer a different look and feel (because we're a way's off from being able to control that text with CSS across the common browsers).

The other thing I'll point out here is that I removed all the &nbsp; character entities. This is of course not a framework issue, but I think its important for people to know. The style attribute white-space:nowrap; takes care of this for us by eliminating the need to use non-breaking spaces to prevent wrapping, which has a number of advantages, not the least of which being that you don't have to type all those entities... although ultimately I wouldn't prefer to place that in an inline style attribute, I would move it out to an external style sheet.

So long story short, the above code is cleaner and less error prone.


New AJAX Feature - <tap:div />

So I just added an item to the framework's default stylesheet for <tap:div /> and also added it to the documentation for the xhtml tag library (which incidentally shows up both under function libraries and custom tags in the docs). You know all the underlying structure was already there, it just wasn't plugged together this way, but now you can use tap:div basically the same way the CFDIV tag works in ColdFusion 8 -- any links inside the div will fetch content via a framework gateway element (AJAX). So here's the code I tested it with.

<cfparam name="attributes.submitted" type="string" default="" />
<cfset attributes.submitted = val(attributes.submitted) />

<div xmlns:tap="" style="margin:20px; text-align:center;">
<a href="?">
<tap:url name="submitted" value="attributes.submitted+1" />
click me!
<div>You clicked the link <tap:variable name="attributes.submitted" /> times.</div>

So all the XSL sheet is doing is a real simple copy of the div and its attributes and then adding a tap:gateway inside with a gaterespond event that imports the returned content to the gateway's parent element. So it's the same as if you had written this:

<tap:event name="gaterespond">
<tap:import target="javascript:element.parentNode" />

... links go here ...

I love it when a new feature comes so easily. :)

BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress