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.

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!

If you search Amazon for Javascript books, you’re going to have a hard time getting started. There are a few that stand out that I’ve been wanting to read though including Pro JavaScript Techniques by John Resig (the creator of jQuery), ppk on JavaScript, 1/e by the guy who runs Quirksmode.org and the bestselling Ajax in Action. The problem with learning “Ajax” most people run into though is that it’s so abstracted by your Javascript framework of choice that very little of what you script is actual Ajax. For that reason these three and the Prototype ones above (which although I haven’t read cover to cover, I’ve probably skimmed through half of while at the bookstore) look like great ones for someone looking to further their JS skills.