Whenever I see any example saying "See how easy this is!?", I inevitably think "What happens when my needs differs a bit from the expected?". My worry is that I could start with a situation for which the tool is a good match and then things change a bit. Do I have to abandon the tool altogether in those cases? Basically, I always want to know how much elasticity any solution has.

More often than not, it seems, systems that are extremely efficient have very little elasticity (think of airline schedules where bad weather anywhere effects flight patterns everywhere). I think that the past several blog entries on Super-Easy CRUD/File Management have demonstrated that the com.sebtools package provides great efficiency for basic CRUD and file tasks. What it hasn't demonstrated (yet) is how elastic it is when the problem is more complicated than what com.sebtools is built to handle.

[More]

We have come a long way in our question to easily manage records and files. Taking advantage of the com.sebtools library, we have a single file that effectively provides a component for every table and methods for every basic action on that table. I would like to focus in a bit more on the API for these components now. Specifically, I would like to focus on how we can get the recordset we want - even for operators other than equality.

What we want is to be able to specify the exact recordset that we want - which columns, which rows, which pages - by passing in arguments. Ideally, we could do this just in our data definitions without writing any extra code.

[More]

In the first entry on "Real World HTML", we reviewed the design (functionally matching a site I recently completed) that we must implement and created the skeleton HTML and CSS. Now it is time to implement the header (or banner) of the design.

Let's start off by taking a look at the banner. Here is the banner in its two states:

[More]

Today we continue our quest to use com.sebtools to easily manage records and files in our example HR application. So far, we have defined our data set with XML, gotten that definition into Records.cfc, and consolated our multi-table application with ProgramManager.cfc. The last step wasn't necessary for a multi-table application, but does make things nice.

What we don't have, however, is any interaction among our tables. We have Departments and Employees, but no relationship between the two. For this example, an employee can work for one (and only one) department.

There are a few pieces of information that are helpful for most of these sorts of relationships. We would like to know the name of the department for every employee (and perhaps a boolean indicating if that employee is in a department). We would also like to have the number of employees for any given department and a boolean indicating whether or not that department has any employees. Fortunately, Manager.cfc can provide all of this for one short line of code.

[More]

HTML5 is currently all the rage. But while people are busy discussing the latest and greatest, maybe it is a good time and step back to look at how to write solid HTML4. Most of the HTML I see, frankly, could use a bit of work. I want durable HTML. Since I don't see that written about enough, I thought I would pick up the gauntlet.

First, I should define "Durable HTML". By this, I mean HTML code that can take a hit and withstand the unexpected. For example, what happens if a manually cleared float is added to the main content area of the page. Does it mess up the design? What about a wider-than-expected image or contiguous text string? What if the text is much longer than expected - making your site taller than you originally guessed? What if JavaScript is disabled?

How easy is it to make changes that - to the client - look really easy to make? What if they want to change out an image in the header? What if they want to change the width of the site or center it?

These are just some of the things that are easy to fail to anticipate when writing your HTML. Very often I see HTML that works, but only if everything continues to be as it was when the code was first written. When that code falls apart, it often does so in glaring ways. The key is to avoid obvious failure.

Rather than trying to speak in abstracts, I am going to take a real world example and work through it - using a site I actually did recently for a client (with different text, colors, and images). I will cover exactly what I did on this project for my client as well as things that I might have done differently if I had it to do over again (I usually have at least one of those for any given project).

[More]