>>>>> "Steve" == Steve Pitchford <[EMAIL PROTECTED]> writes:

Steve> To be honest I'm not sure I follow your argument. Why does populating a 
Steve> from incoming form data require "closer integration"
Steve> than, say, pulling it out of a database and populating a form for further
Steve> editing?.

It's the stickiness, which is a handy feature of error-page generation.

Using the existing CGI.pm, I can say:

        print textfied('first_name', 'default value');

and the first_name field will have 'default value' *unless* there's also a
param('first_name'), in which case it'll come from there.  Of course, I can
specify override => 1, or even delete the param as needed, if I don't want the
sticky behavior.

To get this to work right, whatever I use for HTML generation needs to know
how to get incoming params.  Admittedly, the interface is simple, but it would
have to know if I'm using a functional form with a hidden object (use CGI
qw/param/) or an explicit object (my $q = CGI->new). And if it's an
explicit object, how will the HTML generation find it?  This works
even for select-multiple forms, which is very nice.

That's why the *tight* integration of incoming parameters and HTML
form generation is a Good Thing.  90% of the time, it just Works.

Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Reply via email to