Posted by Toby A Inkster on 05/21/07 09:20

Jon Slaughter wrote:

> If anyone things this thing might be useful then I'm thinking about
> rewriting everything and make it a little more clean. What it does allow one
> to do is treat forms as inline objects that are not event driven. The
> drawback is that the code to handle them must be in a string instead of
> actual php code that will be parsed, say, by an IDE. Maybe someone knows of
> a way around this or has some idea to make it better(I know there are going
> to be the regular nay sayers but who knows).

What you're describing sounds fairly like my form handling code for
demiblog <http://demiblog.org/etc/forms>. Using my form handling classes
you can do something like:

$f = new DBF_Field_Text('foobar', 'Default value', 'Label:');
$f->set_validity_check($blah, TRUE);

$blah is a string which is eval()ed to check the validity of submitted
data. However, I allow an alternative syntax:

$f = new DBF_Field_Text('foobar', 'Default value', 'Label:');
$f->set_validity_check($blah, FALSE);

Here, $blah is a variable of type callback (the callback pseudo-type is
defined here: http://www.php.net/manual/en/language.pseudo-types.php)
which is passed to call_user_func().

That way, you can write a normal function -- say, validate_email() -- and
create a form field like:

$f = new DBF_Field_Text('email', 'you@example.com', 'E-mail:');
$f->set_validity_check('validate_email', FALSE);

I also have a few common validity checks built-in, such as checking that a
field is numeric, checking a field is not left blank, and so on. These are
checked not only after the form has been submitted, but by a special piece
of client-side Javascript too.

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux

[Back to original message]