Define 'better' :-) [+ some examples]

The former method is like the following:

input_select('d_name', null, null, $name_list, 30, 'selectName', false, true);

The latter method is like the following:

input_control(INPUT_SELECT, 'd_name', null, array('list' => $name_list, 'changehook' => 'selectName', 'multiple' => true));

In my experience in this application, I find the latter to be far preferable.

Actually, that's not a wonderfully good example. We had a series of functions with different argument orders for creating various HTML form controls. Most of them suffered from the option-itis we've been discussing, and there were many features most of them could share but did not because it would involve copying code. So I created a single function that could draw any form control, given the right combination of parameters. The first three were the type, it's name and it's value. The remainder were provided in an array. The biggest advantage this gave me was that now all types support the same variety of parameters, including several that are available because they are all HTML tags.

An object-tree might work for this API, though it would probably involve replacing lots of single calls with three or four lines of code. :-/

Wrapper functions could work, too, though there are still four or five parameters that would be optional for all variants. Hmm.

Wade.

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.

Welcome to IWETHEY!