How An Idiot Developer Solves a Problem, Part 1

The situation: I have a "contact us" web page where the list of available subject lines changes depending on what the user selects from the "who do you want to contact" drop-box. While my department is responsible for code, content is controlled by another person in a different department, and that person is going to need to be able to add and change subject lines with as little pain as possible. They'd also like to be able to add new contacts.

The thought process: I know the person who's going to be editing the page for the foreseeable future, and she's comfortable with HTML, but not with programming. I could probably get her to be cool with entering everything into an XML config file, which would allow easy deployment of new data, and be cool; because developing with XML is always cool, right? However, any new contacts she'd want to add would have to be added to the database, requiring intervention by DBAs anyway. Unless, of course, I don't use that particular database table. This is a standalone site, and one of my mandates is to make this site as hands-off as possible for developers. So if I teach the content owner how to edit an XML file, and put everything in there, effectively bypassing the DBA group, then she gets to maintain control of the content, and developers hopefully won't have to get involved so much. Also, I've heard reports that using the current method, where she edits .asp pages directly, that she's accidentally messed up code or sent the wrong file for updating. So if I do this via XML maybe that'll reduce both types of errors.

Okay, so I'll make a config file. What's at the top of my heirarchy? These things are grouped by Categories, so we'll make that the root, containing individual Category elements:

<categories>
<category>
</category>
<categories>

Lesseee, then I guess it'd make sense to have an element describing who to contact, and what the name of the category is:

<categories>
<category>
<name></name>
<contact></contact>
</category>
</categories>


By the way, I name my elements as simply as possible, i.e., one word and lower case, whenever possible because not only am I an idiot, I'm lazy, too. Now what to do about those email subjects? I could make a new file, I guess, but for this app they're bound to the category, so it makes sense to me to make them children of the category element, just like name and contact:

<categories>
<category>
<name></name>
<contact></contact>
<subject></subject>
</category>
</categories>

...and of course I can have as many subjects as I need. I'll never be transmitting these xml files as far as I know, so I'm not gonna bother writing a schema right now. I suppose I'm violating all kinds of xml best practices here, aren't I? I should probably have written a schema first, and my grammar is awfully specific. I mean, it's one thing to write an app-specific grammar, but my grammar is specific to one page of one app. That's gotta be wrong in all kinds of ways, but I'm gonna do it because it's quick, and solves my current set of problems in what I think is a reasonably elegant way.

See, this is what it's like to be an idiot programmer: I really do mean well, and I want to solve this problem in the most elegant way possible, where elegance doesn't just mean I'm programming elegantly, but that I'm also being politically elegant by making all the people happy that I need to: I'm getting done quickly using existing tools, I'm not bothering other developers and am trying to reduce further bother, and the content owner gets to keep her content. However, I always feel like there's a piece I'm missing: like there's probably some super elegant, abstracted way to do this such that the xml is reusable and infinitely extensible, and the app could be ported anywhere without any code reworking going on. But I need to get this done now. So on I go.

So but so anyway now I have an xml file. What do I do with it?

To be continued...