Facebook got tokenized input right. If you’ve ever sent someone a message, or searched for someone a message you probably used what was previously a less user-friendly system to perform this same task. The idea is easy – you want to enter one or more names or other text and select matches. Gmail uses the same kind of auto-complete to allow you to email to multiple email addresses, as do a host of other sites, so it’s surprising there aren’t better solutions to this in the public. I came across one amazing solution for this when I was working on MovieFly a few months ago, and was able to expand it with a few more options while working on SponsoredTweets.

The jQuery Tokenizing Autocomplete was released last year, with some nice additions to it in December. It’s an extremely rich plugin that behaves very similar to the Facebook version. You can select previously entered tokens and delete them, navigate completely by keyboard, or with the mouse – it’s amazing. There’s a few things that came up that I’ve added to it:

initialValues option

First is the ability to pass in a javascript array of initial values via the initialValues option. This is real simple:

$("#tokenize3").tokenInput("response.txt", {
  initialValues: [{"name":"The Dark Knight (2009)", "id":"12345"}, {"name":"Sweeny Todd (2008)", "id":"45334"}]
});

Real straightforward. When the page loads, the token input will be created with these two tokens pre-created.

defaultOptions

On MovieFly when you’re entering a movie for a viewing (that would show up on your recent viewings page), one thing thing that made sense to do was to have a way to pre-fill the list with some commonly used movies. So maybe you want it to show “new releases” since that’s what a large percentage of people are going to use. Another case might be if you want people to tag themselves (or something), and you want to show common tags. One easy way is for the “hint” to link to a list of common tags. Codewise it’s basically the same as initialValues.

$("#tokenize4").tokenInput("response.txt", {
  hintText: "Type a movie title, or see the <a href='#' class='defaultOptions'>current releases</a>.",
  defaultOptions: [{"name":"Hot Tub Time Machine (2010)", "id":"12345"},
                             {"name":"Clash of the Titans (2010)", "id":"12345"},
                             {"name":"Date Night (2010)", "id":"12345"},
                             {"name":"Alice in Wonderland (2010)", "id":"12345"}],
});

The key is the link with a class of “defaulOptions” in the hint text. The plugin finds this link and pre-fills the suggested matches when clicked.

The code is available on github, or check out an example of these and the basic behavior of the plugin. There’s already some great forks of the initial code, so seeing what other great additions have been made.

As some others have mentioned, it’s that time of year where most people with blogs make their public announcements on what languages they’ll be concentrating on for the upcoming year. Last year I think my top focus was Ruby on Rails and Javascript; so safe to say I’ve gotten a little experience in those. Things have taken a bit of a turn though, and I’m going to switch things up for 2009 and concentrate a little on my weaknesses and a little on new growth.

Weaknesses? Yeah, everyone has them. Those areas where when you have to implement something you bite your lip and find a way to get through it — usually with a 10ft poll. If they’re something that ties into your daily routine in some way, this is kind of task that can be holding you back from potentially getting more work done, or higher quality work.

One of my weaknesses has always been testing. Maybe I’ve been surrounded by too many testers, but its definitely something I could improve on. I wouldn’t consider myself fully proficient in a language to the point where I’d feel confident teaching someone else until I was proficient testing in it. Some languages don’t make this easy of course. Testing Javascript isn’t the most common thing, but it’s important, especially with such a Javascript heavy application as CloudShout. There are some great new tools like FireUnit for testing in Javascript too. Testing in Python, especially within Django has to have great support — as long as you actually do it. With Rails there’s a million different ways to test; but I’d like to concentrate mostly on mochs and stubs for a swiftly running test suite. No point in having a test suite that takes so long to run that no one has the time to run it after all.

There are a few other topics of interest for the new year. Things I’d love to look into and play around with at least a least a little. XMPP and especially bosh look extreme interesting to me, and I look forward to cramming together the little I’ve learned so far into an Adogo presentation in a little over a week.

Collective intelligence looks like another interesting topic that I’ve always wanted to dig a little deeper into. The Netflix prize looks an great way to experiment a little with it in some different language — Python, C and Erlang seem to be the most commonly used for it. There’s at least one active Rails plugin for collective intelligence, acts_as_recommendable, that uses a C implementation for the heavy lifting and might be worth checking out as well.

Last year git took over in a lot of programming world thanks to an amazing killer app, Github. Getting familiar with git isn’t a big thing, but it’s worth it to have a little more shared language with your peers. Moving from CVS to Subversion wasn’t something that most people did overnight, but after the switch no one ever went back. Git is shaping up to be same, but has a long road of public support and client side tools ahead of it before it makes it that far. People that like git, really really like git. I’m ashamed to say I’ve made improvements to a few projects I’ve cloned from Github, but never got around to branching and committing my changes (or writing tests for my changes of course). This is something I’d love to get better at — more for fun and familiarity with git than anything else. That’s the goal for this year — work on projects that are fun!

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!