I spent a lot of time wrestling with the question of how to design a good interface for writing HTML myself. I was doing it in VB however, and what works well in one language doesn't always work well in another. And in any case, I was never able to find a totally satisfying solution.

I tried a couple of different styles of function interfaces. I also futzed around with object oriented solutions, which I selved more because I wasn't in a posistion to suggest such a radical change in a system that was otherwise totally procedural.

I ended up going with a large library of functions. It was ultimatly a question of it aesthetically looking better to me then putting it all in one big function and using lots of named parameters.* However, if I had to do it again, I think I would try to split the difference. Have a seperate function for each of the types of HTML controls, but have named parameters tacked on the end for the rarely used options, plus various wrapper functions that cover the most commonly used specific controls that do nothing but setup parameters and coll the underlying generic function.

The interface would end up looking something like this
HSelect (Name, Size, manditory parameters, optional parameters)\n  HDateSelect (Name, StartDate, EndDate, optional parameters)\n  HStateSelect (Name, optional parameters)\nHInput (Name, Size, manditory parameters, optional parameters)\n  HDateInput (Name, valid date range, optional parameters)\n  HSSNInput (Name, optional parameters)

HDateSelect and HStateSelect would just convert their inputs into the generic data taken by HSelect and then call that function.

However, from what I read in your post, I suspect you lean heavily the other way. You would rather have HControl (Type, Name, Size, manditory parameters, optional parameters).

Jay

* Technically speaking, named parameters and optional parameters are two different things in VB. But in practice, the only reason to use named parameters is that they are cleanest way to do optional parameters.