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're talking about. But you do, so I'm a bit puzzled as to why you would say this. Could you explain your point of view a bit further? The only coupling needed is the getting of "param"s. This can be done perfectly by passing the CGI object, or (uglier) by using a subclass of CGI.pm. In Perl 6, it can be done by adding HTML generation as a role to the existing object. In fact, CGI.pm itself only uses ->param and utility functions that are specific to HTML generation, in methods like _textfield. > You couldn't just use two random modules for that... they'd have to > specifically know about each other and work together. There's a tradition of treating CGI.pm's param method as an known protocol, and often you can pass a CGI object, or any other object witha similar param method, to certain modules. One of them is HTML::FillInForm, which proves rather directly that no tight coupling or integration is needed, at all. A simple method with a strict definition is enough, and CGI.pm has provided just that. It's okay to have two modules that were designed to work together, as it is okay to have one module depend on and use another. Otherwise, why would you still want to factor things into separate modules anyway? Maintenance and usability are important issues, but being able to use only what you need is quite attractive too. CGI.pm uses elaborate autoloading techniques, that would not be needed, or could be much simpler, if there was clear separation of tasks from the beginning. > That's why it's great that it's all in CGI.pm. If I just want param > handling, I import/compile only that part. If I also want sticky > forms, I just ask it for a bit more. And as long as I'm there, I > import "header" or "redirect" or "cookie" to do that "last bit" of my > application. CGI.pm has the *right* mix for small tasks. It *does* > make sense. 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 nicely named, grouped, and reasonably standalone roles or classes, and then a single module to combine them all for the ease of use that you like. -- korajn salutojn, juerd waalboer: perl hacker <[EMAIL PROTECTED]> <http://juerd.nl/sig> convolution: ict solutions and consultancy <[EMAIL PROTECTED]>
