Re: Form display and processing module?

Rasmus Lerdorf wrote:

We have always avoided having anything in the core spit out HTML (except for phpinfo) and I really don't see a strong reason to change that stance.

I understand the arguments for this and I think for the most part they make sense. I see this kind of extension, however, playing the same role as something like PDO would in the core: providing a standard way to interact with an external resource that is part of an overwhelming number of PHP programs. In PDO's case, it's a database. In this case, it's a web form. Yes, there are a million non-portable things about every database and many users want to do a million customized things with their web forms. However, I find over and over again in training classes that users are consistently surprised and frustrated with the amount of work they have to do to display, validate, and process a basic web form. I don't think they would be surprised if they were using a different language. But because, in large part, PHP's pitch is to "solve the web problem", it seems incongruous that one of the basic building blocks of solving that problem is not made as easy as it could be. It's as if instead of htmlentities() users had to rely on strtr(), or instead of the $_GET/$_POST superglobals users had to parse the query string or the post content themselves. The lack of this standard form handling mechanism definitely keeps things flexible for intermediate and advanced users, which is good. But it is daunting to many others. So, like I said, I can see the good reasons for excluding HTML generation like this from the core. I'm just trying to be clear on what problem I think it would solve.

If something to do with input validation is going to go into the core, it would be a default generic input validation filter that I added an API hook for a while back. Providing some common input filters would be much more useful than a specific HTML-generation mechanism like this. Of course, the i18n aspects of input validation are daunting, so I don't know if we will ever see such a standard filter. I would suggest you look more at what sort of generic data manipulation functions are needed to make any sort of form validation easier to implement? Perhaps some extra array manipulation functions for checking whether a set of results are in the selection array? I don't think in_array() is quite flexible enough for a multiple select list, for example.

There are some areas for improvement here, but input validation is not my main concern. There are many cumbersome steps required for, say, generating a <select> menu with appropriate defaults. Here's a function that handles single or multiple valued select menus: function input_select($field_name, $values, $options, $multiple = false) {

    // print out the <select> tag
    print '<select name="' . $field_name;
    // if multiple choices are permitted, add the multiple attribute
    // and add a [] to the end of the tag name
    if ($multiple) { print '[]" multiple="multiple'; }
    print '">';

    // set up the list of things to be selected
    $selected_options = array();
    if ($multiple) {
        foreach ($values[$field_name] as $val) {
            $selected_options[$val] = true;
        }
    } else {
        $selected_options[$values[$field_name]] = true;
    }

    // print out the <option> tags
    foreach ($options as $option => $label) {
        print '<option value="' . htmlentities($option) . '"';
        if (array_key_exists($option, $selected_options)) {
            print ' selected="selected"';
        }
        print '>' . htmlentities($label) . '</option>';
    }
    print '</select>';

} To redisplay the menu after form submission with any selections preserved, you'd call it like this: $colors = array('red' => 'Red', 'green' => 'Green', 'blue' => 'Blue'); input_select('color', $_POST, $colors, true); This kind of form widget display is, I think, a common operation, and one that takes way too much repeated code each time some random user needs to do it. So it's these kinds of things I'd like to see simplified. David