|
|
|
relationships with tools
Thursday, November 29 2007
Admittedly, the work I put into the data import tool I'd built yesterday had been a form of procrastination. Building, perfecting, and honing tools built entirely of computer code might not sound like procrastination to a non-programmer, but anyone who loves coding will identify with what I mean. Coders fetishize programming tools the same way carpenters fetishize those of the wood-working kind, knowing the relationship being formed will be a lasting one. Projects come and go, but tools join your personal team like the accumulation of wisdom itself. With code, though, the distinction between tools and actual products is much blurrier than it is in carpentry. A good cabinet is not easily copied, but this is not true of code. Code that drives deliverable products can be modified and reused endlessly, so long as the coder finds himself tackling the same problems over and over.
Today I spent most of my time building a product, not a tool, but as I worked on it I was ever-mindful of the separate, entirely self-imposed goal of producing code with a wide range of applications.
The code I wrote today was for the display of the data I'd imported with the tool I'd built yesterday. Though that data was in a database table, it was basically a flat Excel file, with no relations to other tables. It was a list of stores, each of which had an address. The components of those addresses were geographical hierarchies explicitly spelled out in strings: United States, CA, Los Angeles, those sorts of things. My job was to build a tool that allowed a user to drill down to the stores through a series of menus at each level of the geographical hierarchy.
I decided to handle the entire problem in Javascript, though without the complexity of AJAX techniques. I used PHP to dump the entire store table into a double-delimited Javascript string, and then I built a series of functions that parsed this data, displayed dropdowns, and then responded to changes in those dropdowns by creating the next dropdown in the geographical hierarchy. Virtually none of the resulting code was special-purpose. There was one function to draw a dropdown. Another function displayed user-readable information about a store. Another function deleted dropdowns when a change was made at a higher level in the geographical hierarchy. And another function incremented a counter allowing the program to draw the next dropdown lower into a hierarchy. Those functions, along with a few tiny helper functions, was the whole thing. To get this system working all I had to do was specify a sequence of field positions representing the locations in the double-delimited data of the names of the entities in the various geographical hierarchies. This sequence allowed the system to know which dropdown to create next when one of the higher-level dropdowns was changed.
By keeping all of this code completely generic, I made it easily-adaptable to any sort of web-based spreadsheet walking application.
Still, working on this code was a bitch and at times I'd run up against such serious difficulties that I was tempted to give up. Javascript isn't as easily debugged as PHP, and when it breaks it can do nasty things like crash the browser or throw it into an endless unstoppable cycle of alerts. But, knowing I was building something of real long-term utility, I persevered and was eventually rewarded by success.
It bears noting that I would have had a much easier time of things if Javascript came equipped with some way to create and populate SQL databases entirely in the browser. Without SQL, I was forced to rely on an arsenal of functions with origins in a time when I needed to do database-like things but hadn't yet been granted access to an actual database. These functions can do things like confirm whether or not a string is present in a delimited list, or look up an item in a double-delimited list given another item in its "row" of data. Fortunately, Javascript does have a command for sorting arrays, which made ordering the dynamically-drawn dropdowns a snap.
For linking purposes this article's URL is:
http://asecular.com/blog.php?071129 feedback
previous | next |
