Thanks to our mutual friends at the Internet Archive all my old posts are back*. I still don’t have the comments but I doubt I would have bothered to copy those from the old server anyway. Enjoy**.

*: Almost all, it hadn’t archived the memorial post and I’m not sure I want to re-post it anyway. **: And sorry for the flurry of re-posts for those who have read all these before.

This is really becoming a habit. I post a few articles, become silent for a while, take the blog offline for one reason or another and then put it back online again just to repeat the whole cycle again. As usual, I’ll try to get the articles from the last run posted soon. I just have to make the time to fire up the old server and nab them. The new server I’m running things on now should be considerably more stable as it’s completely new hardware – the old server was older than both my kids combined!

Note: For those finding me from Abel Keogh’s site this, believe it or not, is an old blog. Just one that gets a fresh start relatively often. If you’re only interested in the posts related to the loss of my wife and how I’m learning to live on, please check back in a few days when I’ll have a separate RSS feed available for just the Life related posts or you can simply bookmark the section and visit every now and then.

Update: I knew this worked but I had to track it down to make sure… Here is the feed for the Life section.

Sorry to keep the trend of meta-blogging but my life really is that boring otherwise so here goes…

In my last post I decided to let everyone know how I went about implementing that nice little search form trick of having the form input itself be its own label. Just check out the post for the details. Looking at this it was a working solution but it seemed ugly and as though there was too much of my code there. So lets see what I’ve done now.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

var DefaultField = Behavior.create({
  initialize: function(options) {
    this.options = Object.extend({ className: 'default' }, options || {});

    if (!this.options.defaultText)
      throw new Error('FieldDefault: Must provide defaultText value');

    this.onblur();
  },
  onblur: function() {
    if (this.element.value.blank())
      this.element.addClassName(this.options.className).value = this.options.defaultText;
  },
  onfocus: function() {
    if (this.element.value == this.options.defaultText)
      this.element.removeClassName(this.options.className).clear();
  }
});

Event.addBehavior({ '#q': DefaultField({ defaultText: 'live search...' }) });

It’s not particularly shorter or cleaner, in fact I really hate the fact that almost every line has this.element in it multiple times but there’s one important difference between this code and its predecessor, it’s re-usable! The previous implementation was directly attached to the element and did not allow for any re-usability without being duplicated. Now I can re-use this behavior in a test suite and quickly verify it’s function in many browsers very quickly. I can also use this behavior elsewhere that similar functionality is desired and I don’t have to copy and paste the code.

There’s also a hidden value to this technique. Had I re-used the previous implementation over several portions of a larger system and then decided to change how the default value was displayed, say I wanted to make it an overlay so it doesn’t impact other behaviors like live search where you may want to observe the field value for changes to fire off a search, I’d have to go modify at least a few of these implementations. This modification would have left me with different implementations of the same idiom without any way of telling them apart without digging through the code. By bottling this up in a behavior I can have multiple implementations with each having a descriptive name and appropriate documentation. More importantly, I can change all of them in a single place which makes it more maintainable.

Again, if it wasn’t obvious this post relies upon prototype.js and now also upon LowPro. Check these libraries out if you haven’t already and make sure to look at them from the perspective of not necessarily just letting you keep your JavaScript out of your HTML, but also letting you bottle that JavaScript into more re-usable chunks because after all the last thing we want to do as programmers is write more code.

This is a really simple thing that I’m sure dozens of other people have already implemented over and over by now and that’s not counting the hundreds whose Mephisto theme doesn’t do this out of the box.

Basically I wanted my new theme, wibbish, to have some sort of label for the search box. Here’s my take on creating an unobtrusive default for the form field like you see on many sites these days. The idea is simple, when the form field is not focused and has no user entered value, it should have a CSS class appended to it so that its styling clearly indicates it’s in a default state while at the same time have its value set to some sane value that would work as a label in a traditional form layout. Once the field becomes focused, that new CSS class and default value should be removed to make it easier to modify the form field.

Now to cut to the chase, here’s the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Event.observe(window, 'load', function() {
  // grab a reference to the search field
  var q = $('q');

  // add a focus and blur handler to the search field
  Object.extend(q, {
    // set the default text as an attribute of the object so it's only set once
    defaultText: 'Search',

    // simple onBlur handler to add a "default" class and text to the field
    onBlur: function() { if (this.value == '') this.addClassName('default').value = this.defaultText; },

    // simple onFocus handlers to remove the "default" class and text from the field
    onFocus: function() { if (this.value == this.defaultText) this.removeClassName('default').clear(); }
  });

  // attach our handlers
  q.observe('blur', q.onBlur.bindAsEventListener(q)).observe('focus', q.onFocus.bindAsEventListener(q));

  // finally just trigger the onBlur event handler to initialize everything
  q.onBlur();
});

Of course, now that I’m done with this, it’s time to try writing a plugin or patching Mephisto to have an unobtrusive live search.

Update: As if it wasn’t obvious, this is all based upon the excellent prototype library.

As I’m sure others have encountered who chose to deploy a standard mongrel/rails setup, my site has never been able to auto-recover from a hardware related restart (read crash/blackout/etc). Well, it would seem that the newest mongrel_cluster gem added a “--clean” option to the startup that removes stale pids that would otherwise keep mongrel from starting.

This is great. Now I get to delete my completely non-functional cleanup script that I’d written to do this at boot time. Do you really want to keep power-cycling to figure out why it works when run by hand but fails miserably when run at startup? After I spent a few hours one night trying to figure out the cleanest way to parse out the pid_file entry from the various cluster configuration files in /etc/mongrel_cluster to be able to properly cleanup after a crash and never really liked what I had to do to get the right values out of that, the dang thing never worked and I have had to manually log in after each “outage” to fix it. At it never failed that I didn’t notice any of the times the site was down for at least a couple days so I doubt anybody thinks my site is even alive anymore.

Now I simply update the start form of the mongrel_cluster init script to call --clean and I’m done. Mongrel takes care of itself now. There’s hopefully some really elegant code somewhere in mongrel_cluster or mongrel_rails that deals with parsing the pid_file configuration line and hopefully the dang thing works during boot. The first hope is as easy as reading the code, which I’ll do later, while the second isn’t something I feel like testing right now so only time will tell.

The funny thing about this whole story, at least what I got out of it, was that if I had first just checked for updates, I would have saved myself a night of trying to figure out how to cleanly parse the pid_file config line and the headache of seeing the thing not work. So the moral, boys and girls, is to always check for updates, it could save you a lot of time and maybe a headache or two.

This is getting really old at this point. I’ve now rebuilt this stupid site for … I’ve lost count how many times I’ve done it now. But I’m running on Mephisto 0.7.3 and Rails 1.2.3 now so I know things won’t change and I don’t need to bother with updates that are going to break stuff. I’ll still get bug fixes though as I’m using svn to maintain them.

Who knows, maybe this was the spark I needed to start blogging again. We’ll see.