Your Linux Data Center Experts

The DRY principal is all the rage in web development these days. It stands for “Don't Repeat Yourself”. It's basic idea is that you should have information in exactly one location, not duplicated in several. In general, I'm all for it. If you have the same information in multiple places it makes it harder to keep those places synchronized. However, I ran into a case where DRY, taken to it's extreme, just kicked my butt.

On the web-site, there is a menu on the left which changes depending on where exactly you are. When you first go to the site, the menu is a list of the major topics. If you go to one of these sections of our site, the menu will open up to show more selections for that sub-section of the site. There's another level of expansion as well as you get further down into the site.

Originally, I had the menu coded up as a simple data-structure which gave the hierarchy, hrefs, and anchor titles. I then had another data-structure that had some simple rules about expanding and collapsing the different parts of the menu based on the URI that was being loaded. I then had a pile of fairly complex code which took these two sets of data and produced the menu for a given URI as the page was rendered.

The code that applied the rules to the menu structure involved several functions, and something around 100 lines of code. It mostly worked, but it was complicated and changes to the menu rules almost never “just worked” and required debugging to figure out why they were doing the wrong thing. Evelyn could never make a change to the menu at all, and I usually had to spend half an hour figuring it out…

There was absolutely no repetition of information. The menu was built from a single structure and rules which were applied on it. And it was totally unusable…

This was built before DRY was such a big deal in the web development world, but this implementation, in many ways, fits the ideals.

This morning in the shower, I came up with an idea of using a static menu made up of the raw HTML, with some simple “span id=” tags around the various sections I wanted to be able to expand or collapse. The menu is always the same, and a simple chunk of CSS defines which of them are visible. This does require more repetition however, because I have a list of the sections which exists in the code, but has to map to the HTML menu structure.

The plus side is that the code which deals with the dynamic structure is only around a dozen lines. An order of magnitude better than the old system. Plus, it's much more understandable than the old code. While I did add some testing code, my first implementation and set of rules worked perfectly.

The down side is that this doesn't work with non-CSS browsers. To be precise, non-CSS browsers show the whole menu on every page. The old system, when it worked, would show the right links on every page. I could come up with some hybrid that is somewhere in between these ideas, but that's not at the top of my list right now. Better form handling code is a much higher priority…

I realize some of this may be a “Duh” for people who do a lot more web development. I'm constrained by wearing many hats – why else would I be fixing this problem on my holiday? Sadly, that constrains how clever my solution is going to be. I also have no budget for outsourcing this sort of thing, which means either I wear the hat or the hat gets neglected.

Sometimes, keeping it simple is more important than not repeating yourself.

comments powered by Disqus

Join our other satisfied clients. Contact us today.