February 8th, 2008 by ymendel 2 comments »
Everybody loves chronic, right? It makes life so much better. But it makes you lazy. I should know. Seriously, I thought I was lazy before chronic, but that was nothing compared to now.
People like being on the chronic and everything it does for you, but it gives them weird ideas. They want it to do more for them.
Look, I'm done with the marijuana innuendo. For the people still confused on the matter, I'm talking about the natural language date/time parser gem.
Greg Pierce pointed out an easy way to get nice "smart" date fields using chronic, but it left something to be desired. Maybe I'm the oddball here, but it seems many Rails developers are all about the callbacks, all about the
before_validation. That doesn't really cut it for me most of the time. It cuts out an entire step of the object lifecycle, that step where
new_record? is true.
Sure, there's after_initialize, but that has its own problems. And even that wouldn't work for this type of situation. You could write your own accessors for every date/time field to do your own parsing (or do so [meta]programatically, maybe even with a plugin), but doesn't Rails already do something with attribute values? After all, all the input comes in as strings that become other objects based on the column type. How hard would it be to add some chronic love?
Not hard at all, it turns out. And so I present to you autochronic. What's autochronic, you ask? It's all in the name: auto chronic. Automatic chronic. It handles all this stuff for you. If you want to say something like
person.birthdate = '1957-03-02', that's fine. So is
rube.birthdate = 'yesterday'. And the best part is it happens right away. There's no futzing with object lifecycle steps, saving, and callbacks; just assign the value you have to get the sensible value you want.
Autochronic --- git it yourself, give it a go. Enjoy life being even better-er.
git clone http://git.ogconsultin.gs/autochronic/
Frankly, I'm surprised this didn't already exist.