Friday December 23, 2005 at 14:06
Subject: DO Repeat Yourself!
Keywords:
Procedure, Technical, Web
Posted by: Sean Reifschneider
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 tummy.com 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.
(Post Reply)
(Post Reply)