DOM tree construction attempts
It was only in the second week into the program that we started working on creating a DOM tree. Trees, organic or data, are pretty awesome. But, a DOM tree is really difficult to build the first time around. We were forewarned that previous students had spent up to twenty plus hours on this project due to numerous road-blocks.
With that foreshadowing, my pairing partner and I, spent a lot of time planning the details of how we were going to create our DOM tree to avoid the possible edge cases that would create an incorrect tree. Better to have a clear idea of how to proceed than to go start coding immediately and have to backtrack later to fix or rewrite that method later.
We decided to build the tree recursively with using a subset of data with each recursion until there were no more nested elements to create the child nodes. Recursion is basically iteration with a stack, but easier to read in code and follow sometimes. The plan was to find an opening tag, grab the data between that and its corresponding closing tag, construct and node, and recursively construct more nodes with the subset of data that was nested inside that tag. Then proceed with the rest of the data.
Implementing it and the additional methods in less than ten hours was a totally different story. The first roadblock a persistent nil error from the html tag identifying method. The same tag method was used twice in tree building method: once to ID the opening tag, and another to find the closing tag. However, the second method was failing to ID a second tag. The method written method had passed all of our previously created specs to check it was working as required. But, I guess the specs were not comprehensive enough to catch the errors we were getting.
The next few hours was an intensive learning experience with debugging our tree building method. First, our tree only had one branch: so the rest of the data wasn’t being processed. Next, the method was infinitely looping: the dataset wasn’t getting smaller. We had probably spent too many hours rereading and testing it that we were overlooking something obvious.
With only two hours left, we scrapped the method entirely. It was a big decision, since we had spent much time planning it. But it was refreshing to start over again and try to solve it in another way to avoid the problems we were encountering. Eventually, David and I built the tree with the new method in less than an hour…
It’s good to not get too attached to the original code until it actually solves what it was meant to do. Sometimes, I’ll have to scrap it because the original idea didn’t work too well, if at all.
Debugging learning experience for the win!