We have already introduced a new form generation API
. But generating HTML inputs is not the only thing that needs a closer look.
The most obvious thing is form validation. So far it has been spontaneous. We know that we can check the input and implode all the error messages in $error_string which then is somehow handled by the output generation code. The problems are:
- Not all scripts may be following this scheme
- The $error_string is a snowball with no structure and control
- Inputs cannot be provided induvidual error boxes
- The layout of error messages is not very customizable
Another problem is not so obvious but it is well-known in the web developers' society: a POST form handler should not display results but should rather redirect to a different results page. In Cotonti this is currently true only for some essential forms, while most forms display results and error messages on the same page as POST form handler. What's so bad about it? Well, if a user clicks "Refresh", double posting may occur. In some other cases a form is handled by a (standalone) plugin and the result has to be returned back to the original (module) page, which is not possible currently (thinking of error messages) out of the box.
I'm currently working on an improved way of handling error messages (during form validation and such). The main principle is simple: once a field validation fails, sed_error() function is triggered to store an error target/message in session and so for the entire form. After that, a redirect to the results page is performed (which may vary depending on success or failure). The results page checks for the error/message information and displays it (if any) in the appropriate places. This approach, combined with existing Forms API and Resources concept, makes possible:
- Standardization of error handling
- Error layout control
- Display of error messages in the appropriate places
- Form handler/results responsibility delegation
Another thing which is in thinking stage is Input Buffering. That would mean remembering input values in the session in case of the error, so it is not lost when redirected back to the form to display error messages.