| Subject: | Forms handling (esp. on creation) |
Handling of forms through Class::DBI::FromCGI is problematic, esp. at the creation of a new object.
An "add" form that fails an untaint check will not return a created object, and thus there'll be no primary key and Maypole can't retrieve the object and it hangs indefinitely. This has been kludged in the newest CVS but the solution is not acceptable; a proper solution must involve returning a user to the otherwise-filled-out form, with appropriate error reports, and not just nuking the whole process. Similarly, an "edit" action where there is an untaint failure will pre-fill the form, but with the values from the database, not with the values from the failed form-filling. In both cases, the form should be redisplayed with the data that failed to validate, and appropriate error messages. (Or, rather, these messages etc. should be available to be displayed; if you want to exclude them from your template, that's up to you.) Presumably this will involve pulling the data from the same place (the form) that instantiated FromCGI in the first place.
I appreciate that this is a problem with CDBI::FromCGI (perhaps not strictly a problem; it's documented behaviour). But in the Maypole context, where we're concerned with the end-user's experience, it's important to be able to properly fill out and validate forms.