* Amir E. Aharoni <[EMAIL PROTECTED]> [2006-09-17 16:25]:
> WordPress is an example of a webserver software tool that does
> try to produce standard XHTML. It does it by default and very
> few bloggers who use it care about it or, for that matter,
> notice it.
Psh, whatever. Everyone serves their
* Randal L. Schwartz [2006-09-19 21:25]:
> The form-generation stuff needs tight coupling with the getting
> (and setting) of the incoming param values. You couldn't just
> use two random modules for that... they'd have to specifically
> know about each other and work together.
Err, no. They jus
Juerd wrote:
>
> It does make sense to have a single toolkit that does all this. It does
> not make sense to have a single .pm that does all this. There's
> absolutely no need for having all these different tasks in one module.
> There's not even any benefit. You can just as well use a couple of
>
Randal L. Schwartz skribis 2006-09-19 8:16 (-0700):
> No, it's an *integrated* task. The form-generation stuff needs tight coupling
> with the getting (and setting) of the incoming param values.
Integrated task? Tight coupling? If I didn't know you, I'd immediately
say you have no idea what you'
Randal L. Schwartz wrote:
"David" == David Cantrell <[EMAIL PROTECTED]> writes:
But don't throw out the simplicity of CGI.pm's basic task handling: parsing
the incoming parameters (including file upload), and generating sticky forms
and other common HTML elements.
Dav
(Randal L. Schwartz) schrieb:
> > "David" == David Cantrell <[EMAIL PROTECTED]> writes:
> David> That's two tasks. It should be two modules.
>
> No, it's an *integrated* task. The form-generation stuff needs tight
> coupling
> with the getting (and setting) of the incoming param values.
A se
> "David" == David Cantrell <[EMAIL PROTECTED]> writes:
>> But don't throw out the simplicity of CGI.pm's basic task handling: parsing
>> the incoming parameters (including file upload), and generating sticky forms
>> and other common HTML elements.
David> That's two tasks. It should be two
