If you’re in the Orlando next tuesday, Feburary 5th, and want to listen to a talk about Reactor, check out Adogo’s February meeting. Joe Zack and I will both be giving a presentation on a ColdFusion ORM, with him doing the also-popular Transfer. I’ll be interested in seeing how the two compare and the discussion that will probably ensue.

A month ago I was talking about designing with grids and specifically with 960 pixel wide grids due to the amount of divisors it has. Over the weekend a new CSS framework called Blueprint was release which emphasizes just those two aspects. Blueprint includes a small set of css files but packs quite a punch, especially for a first release.

There are only 5 css files for the entire framework, split up in designations like “grid”, “reset” and “typography”. A more in depth description of what they do can be found on the Blueprint tutorial page. The concepts make for learning how to create your own designs relatively easy. There are a few basic ideas to all layouts:

1. A div with a class of “container” will hold everything within a box
2. The first item in a container (the one farthest to the left), needs a class of “first”
3. The last item in a container (the one on the right) needs a class of “last”
4. vertical columns need a class of “column”
5. You can specify a class from “span-1″ to “span-9″ to determine how wide a column should be.
6. You can create another “container” within any column and repeat these steps.

A container sets the width to the magic number, 960px wide. This means that if you were trying to make a layout like AdamFortuna.com which has 100% wide portions, each would be it’s own element with a container inside of it, so the header would look like this:

<div id="header">
  <div class="container">
     <div class="column first span-10">
       <h2>AdamFortuna.com</h2>
       <span>Rants on software development, Coldfusion, Javascript and UI Design.</span>
    </div>
    <div class="column last span-4">
       Search form....
    </div>
  </div>
</div>

The “header” would then be responsible for setting the background color. The heavy amount of classes do all the work, keeping your css free of all IDs, one of the main reasons I don’t like Yahoo Grids is that it uses ID tags, not to mention littering your css with “yui” everywhere. Blueprint does a good job of staying towards the semantic css side of things, although ideally you wouldn’t have numbered classes like “span-3″, it would be more like “pod” or “asides”. I’m happy with the mix though, and you can specify additional styles by tagging it up with your own IDs. In the Blueprint example you’ll also see a pair of background images that come along with the framework to use when testing your layouts.

Blueprint is still at version .3, with it just out in the public eye, but I see it being very useful down the line. If you’re pulling your hair out trying to get a normal box layout without tables, it’s a great resource to check out.

The recent discussion of Form Validation – How do you do it?, had me wondering just what might be involved in creating an easy to use validation framework. It’s a task that might seem easy, but when you get down to all the special cases it’s anything but. ColdFusion is a language designed around rapid development, so why not attempt to create a Validation framework modeled around the idea that new rules can be added easily? Ok, that’s probably the case with any such framework, but it should be easy for a dynamic here. Today I’m mostly just brainstorming what I’d want and possible implementations. Over the next few days I’ll try to implement this.

So what should it be able to do? Well, Jeff’s post stated some very important requirements that I’d say are all must haves. To reiterate some of the points though, it should be able to validate entire business objects (cfcs with getters/setters OR named structs), it should be able to have a “strict” mode where it validates everything or a mode where only set fields are validated. It should be able to validate forms via ajax (funcational validation), as well as single fields via ajax. It should also be able to validate from the client side and return error messages (json/html) or validate on the server side and get back some sort of error collection.

We want this to be as easy to use as possible, so the validation rules should only exist in a single place. The ajax features should also automatically call the associated validation rules. One of the difficulties with ajax is always that it requires twice the work by definition, but what if by some convention both Javascript and validation could be written for us? Here’s what I’m talking about.

<form id="register" validate="onsubmit" message="before">
   <div class="group" id="required">
      <span id="register-first_name-field">
         <label for="register-first_name">First Name</label>
         <input type="text" id="register-first_name" name="user[first_name]" />
      </span>
      <span id="register-username-field">
         <label for="register-username">Username</label>
         <input type="text" id="register-username" validate="onkeyup" name="user[username]" />
      </span>
      <span id="register-email-field">
         <label for="register-email">Email</label>
         <input type="text" id="register-email" validate="onchange" name="user[email]" />
      </span>
   </div>
   <span>
      <input type="submit"/>
   </span>
</form>

This basic form would be the basis for how the front end would work. Based on the metadata we’re marking up on the form (namely those “validate” attributes). The idea is that a form has basic validation rules associated with it — when to validate it and where to put the return values. Each field in the form would then inherit the validation rules defined in the form, but could also overwrite them. For instance, this form would validate everything on submit by default, and place and error messages “before” the field they’re for. Other options might include “after”, “top” or “bottom” for the very top of the form, or “above” and “below” for errors to be put at the top of the current grouping. The HTML will require some kind of hooks for where to place these messages of course, which is where some the convention markup comes into place. The before/after messages would look for the formid-fieldid-field element and place it in an element before that. Top/Bottom would look for the formid and place based on that, and the grouping option would look for an element with the class of group that’s a parent element.

Now how would this know where to submit to for validation? That’s another easy convention to handle. Let say there’s three possible things that can be validated via ajax on a form — an entire form, a single object from a form or a single field from a form. Creating URLs for these to submit to might end up with something like this:

http://localhost/validate (validate.index)
http://localhost/validate/object (validate.object?object=objName)
http://localhost/validate/object/field (validate.field?object=objName&field=fieldName)

Using Coldcourse you could create these without much trouble, and the javascript could discover the validation URL to use based on the form field names. The fields are named in the form object[field] which is a Ruby on Rails/ColdFusion on Wheels convention. On the server side these are converted to structures before we ever have to start working with them. This validate controller would then call up some sort of ValidationService where the real meat of the work happens. The controller then knows to return the errors it gets back to the javascript handler based on some sort of Javascript view template.

This is just brainstorming at this point, but looks easy enough to implement. If there’s anything I’m overlooking, or any suggestions with this so far feel free to comment.

Tomorrow: start planning the service layer!