Archive for January, 2008

Sub-Library [Libraries]

Friday, January 25th, 2008

Just about everybody is using a framework or library for something these days. It is the logical next step. When everybody that matters and their mother has weighed in and IT is done as ITs going to be, it is time to lock what ever IT is down. This allows us a foundation to start building a greater ITs, you know? In my newest role, I have formed a bias towards YUI for layouts and javascript though I am fond of a few other frameworks too. Working with these libraries hopefully will inspire developers to start thinking of their work as something that could be re-used. Ideally everybody will see each html document as an API that could be used in a limitless amount of future applications. Even if you are just building a simple page for a one-off project that may never see the light of day, it is still important to think your conventions through.

Javascript conventions

Well thought-out javascript does not stop at the framework level. Creating a huge blob of overly specialized functions that leverage a flexible framework seems wasteful to me. There is so much extra energy that can be harnessed from all of those development hours that you spent toggling the visibility of that light box effect (or whatever). Learn to step back from your specific implementation and write a reusable control. This control would be a simple object-oriented chunk of behavior with a clear set of descriptively named methods and properties. I like to spend a little time brainstorming other use-cases before I begin creating any control. Once your inventory grows a bit you can start promoting your controls to a larger library that can be used for multiple applications. I find that this model, at first seems redundant, but in reality reduces the over-all code on your properties. If you are a freelancer, I imagine that this sub-library can be something that you package and sell to your clients to add value to your product offering.

Markup conventions

Hopefully you are already separating your behavior and style from your markup. If not, read this. One thing that will help you to build reusable javascript controls is a good Markup convention. Every control that manipulates what the user sees will need to work with the markup layer in some way. A little time spent deciding on some adaptable code standards will save you tons of time. Most of this is done for you in the W3C spec. They have worked hard to come up with flexible ways to represent things like numbered lists and definition lists and you owe it to yourself to leverage them. Sometimes however, you will need markup for a more specific implementation that does not match a W3C spec. When that happens try to stay shallow and make sure it works constantly in all browsers. If possible it would be smart to document this convention so that your peers and successors can easily pick up where you left off. I like to think that most conventions can be positioned so that a javascript control will bind to a specific container on a page using a className, then gain access to child nodes of the container relying on your pre-defined markup convention as an API. I suggest using a class because it is possible that your control will be used more then once on one loaded document.

And a little about style

I like to think that this can all be done without applying styles such as font types, images, and colors. With a few exceptions this can all be done through CSS which by now should go without saying.This pattern is one that I have been perfecting over that last couple of years. I am a huge fan of using conventions where possible because, I hate doing the same thing twice. I am sure most of you can agree with that and a lot of you are already applying this in some way.