|
|
|
algorithm development by mutation
Friday, February 23 2007
Using a heavily-modified library of Javascript functions I'd designed for my web-based MySQL table editing tool (which is now my main table design tool), I've been working on a tool for building questionnaires that can accept multiple responses to the same set of questions. Such questionnaires are commonly presented as tables with fixed names for the columns (for example: Name, Phone Number, Extension, Job Title). Such a questionnaire could easily be represented as a single table in the database, but I anticipate there being lots of them, some more disposable than others, so I wanted to incorporate the concept into my existing questionnaire model. In this model, "answers" (the values placed in each cell of the grid) appear as separate rows in one table, while "questions" (the names of the columns) appear in another, and "questionnaires" assemble the questions into coherent sets. Additionally, there's the concept of sort order so I can keep the data in each row associated with its fellows while also representing the order in which they are to be displayed.
The result of my work was a web page that behaved like a spreadsheet. After quickly designing a "questionnaire" using my Tableform web-based system, I was presented with labeled columns into which I could freely type data. If I needed more rows, I'd just click an insert button to build another form row on the fly using cross-browser DHTML. If I wanted to delete a row, I could do that on the fly. I could also reshuffle the rows up and down, exactly the way I can the field names in a MySQL table using my Tablemaker tool.
Since this interface would ultimately be operated by users coming to a commercial website, I had to make its interface a little cleaner than I had my Tablemaker interface. So I fussed for hours over the algorithm that applies an alternating background color to each successive row. To keep coloring glitches from accumulating (something that hadn't bothered me in Tablemaker), the DHTML would have to recolor the rows every time there'd be an insertion or a deletion (and it would also have to swap colors along with content when rows were moved). I'd been working most of the day on this project and I didn't have the mental focus to understand the way recoloring worked, so I just kept trying different random methods (code mutations, if you will) until one of them worked. Everything seemed to be working fine except for insertions of rows at the very beginning of the tabular questionnaire. For some inexplicable reason, the alternating color background kept failing with every first-position insertion. I spent my evening trying different initial colors and inserting lines of code to strategically flip the colors depending on whether or not there was an even or odd total number of rows. Had I just done a few little experiments, I could have seen that there was an error in an underlying part of the line renumbering code and that the color flipping code was basically right. But at this point I was so intimidated by the complexity of this monster I had built that I stubbornly refused to explore how it was operating until I was finally driven to do so by desperation. As always, once I decided to go in and really examine what was wrong, the problem proved to be an easy one to correct.
For linking purposes this article's URL is:
http://asecular.com/blog.php?070223 feedback
previous | next |
