>>>>> "Steve" == Steve Pitchford <[EMAIL PROTECTED]> writes:
Steve> To be honest I'm not sure I follow your argument. Why does populating a
form
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!
