RE: [cgiapp] new competition: CGI::Prototype
In working on the PHP port, I've had a number of people respond asking for more/better usage examples -- and I'm really beginning to think that this may be the key to gaining more 'street cred' among perl developers (though there's certainly plenty already). . . (snip) In short, I think that CGI::Application is *so* flexible that the documentation really doesn't do it justice If you have any examples or code you'd like to contribute to the documentation, I'm certain Mark would be happy to include them ;) My smartassedness aside now, your bulletpoints would make for some great examples. If you have the time and ability to produce these, you'd be doing the community a great service. I personally find it helpful to have some example code to digest after reading the POD of a module. I can't be alone out there in this. And it's one gripe I have about CGI::Prototype. I read the module POD and description and thought, Gee, that's nice. Show me some code and show me why this is better. Ok, I'm done now ;) -- Jason A. Crome Senior Software Engineer, DEVNET, Inc. E-Mail: [EMAIL PROTECTED] http://www.devnetinc.com -Original Message- From: Matthew Weier O'Phinney [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 9:45 PM To: [EMAIL PROTECTED] Subject: Re: [cgiapp] new competition: CGI::Prototype On Thu, 2 Dec 2004 11:19:27 +0900, Thilo Planz [EMAIL PROTECTED] wrote: I just saw that Randal L. Schwartz published CGI::Prototype on CPAN yesterday. http://search.cpan.org/~merlyn/CGI-Prototype-0.90/lib/CGI/Prototype.pm The more, the merrier I suppose... Merlyn's been talking about that for some time on PerlMonks, and brought it up again this week in response to a CGI::Application question. He claims to have gone into the CGI::App source and deemed it too 'monolithic', which I found surprising; he wouldn't elaborate, however. Something I've noticed about CGI::Application -- in part because I did the same thing: people are initially turned off by it as it seems either too complex or non-intuitive (I don't thing these are the same, personally). I know when I first encountered it, I said to myself, What the...? Looks like a lot of work. Then, after developing a solution of my own and looking for a namespace, I ran across it again... and discovered it was doing everything I was, only in a more flexible manner. In working on the PHP port, I've had a number of people respond asking for more/better usage examples -- and I'm really beginning to think that this may be the key to gaining more 'street cred' among perl developers (though there's certainly plenty already). Some criticism of the current usage examples in the documentation: 1) They don't show how template integration really works. I think this is one of the chief benefits of the system. You can swap out template engines easily (even more easily now with the Plugin architecture), and this allows you to stop mucking about with HTML within your script. (There's little worse I like doing than working in two more languages within the same file.) By assigning content directly from your DB or out of files to the template, the script code becomes very clean. 2) They don't show good usage examples of form processing. ValidateRM has achieved a large following (from what I see of traffic on the list), and many of us have rolled our own form validation libraries/techniques that, again, make scripting very clean and simple, while retaining a lot of power. 3) Show an example that has some database or content retrieval from custom APIs. Again -- Class::DBI, etc. make retrieving, adding, and updating content very easy in a CGI::Application - based system. 4) An example of an instance script or CGI::Application-based module being used as a mod_perl handler would be very useful for those stumbling upon the module. 5) A good usage example I can think of would show the creation of a superclass, one or more classes inheriting from it, and explain how the inheritance chain would work. For instance, throwing authorization and a sitewide template into the superclass, and how this would be passed on to the child classes. 6) Show how a single application module can be rendered radically differently based on the metadata passed from an instance script. Again, this is, to my perception, a key strength of CGI::Application -- reusable, customizable web applications are incredibly simple to plan and code. In short, I think that CGI::Application is *so* flexible that the documentation really doesn't do it justice -- and so people are quick to dismiss it and/or develop 'superior' alternatives. And looking at the code -- well, there's so little to it that it's hard to see the big picture -- namely, that by itself
[cgiapp] new competition: CGI::Prototype
Hi all, I just saw that Randal L. Schwartz published CGI::Prototype on CPAN yesterday. http://search.cpan.org/~merlyn/CGI-Prototype-0.90/lib/CGI/Prototype.pm The more, the merrier I suppose... Thilo - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] new competition: CGI::Prototype
On Thu, 2 Dec 2004 11:19:27 +0900, Thilo Planz [EMAIL PROTECTED] wrote: I just saw that Randal L. Schwartz published CGI::Prototype on CPAN yesterday. http://search.cpan.org/~merlyn/CGI-Prototype-0.90/lib/CGI/Prototype.pm The more, the merrier I suppose... Merlyn's been talking about that for some time on PerlMonks, and brought it up again this week in response to a CGI::Application question. He claims to have gone into the CGI::App source and deemed it too 'monolithic', which I found surprising; he wouldn't elaborate, however. Something I've noticed about CGI::Application -- in part because I did the same thing: people are initially turned off by it as it seems either too complex or non-intuitive (I don't thing these are the same, personally). I know when I first encountered it, I said to myself, What the...? Looks like a lot of work. Then, after developing a solution of my own and looking for a namespace, I ran across it again... and discovered it was doing everything I was, only in a more flexible manner. In working on the PHP port, I've had a number of people respond asking for more/better usage examples -- and I'm really beginning to think that this may be the key to gaining more 'street cred' among perl developers (though there's certainly plenty already). Some criticism of the current usage examples in the documentation: 1) They don't show how template integration really works. I think this is one of the chief benefits of the system. You can swap out template engines easily (even more easily now with the Plugin architecture), and this allows you to stop mucking about with HTML within your script. (There's little worse I like doing than working in two more languages within the same file.) By assigning content directly from your DB or out of files to the template, the script code becomes very clean. 2) They don't show good usage examples of form processing. ValidateRM has achieved a large following (from what I see of traffic on the list), and many of us have rolled our own form validation libraries/techniques that, again, make scripting very clean and simple, while retaining a lot of power. 3) Show an example that has some database or content retrieval from custom APIs. Again -- Class::DBI, etc. make retrieving, adding, and updating content very easy in a CGI::Application - based system. 4) An example of an instance script or CGI::Application-based module being used as a mod_perl handler would be very useful for those stumbling upon the module. 5) A good usage example I can think of would show the creation of a superclass, one or more classes inheriting from it, and explain how the inheritance chain would work. For instance, throwing authorization and a sitewide template into the superclass, and how this would be passed on to the child classes. 6) Show how a single application module can be rendered radically differently based on the metadata passed from an instance script. Again, this is, to my perception, a key strength of CGI::Application -- reusable, customizable web applications are incredibly simple to plan and code. In short, I think that CGI::Application is *so* flexible that the documentation really doesn't do it justice -- and so people are quick to dismiss it and/or develop 'superior' alternatives. And looking at the code -- well, there's so little to it that it's hard to see the big picture -- namely, that by itself, it does nothing; as a framework and skeleton from which to inherit, there's little it can't do. -- Matthew Weier O'Phinney [EMAIL PROTECTED] http://weierophinney.net/matthew/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] new competition: CGI::Prototype
Thilo Planz wrote: I just saw that Randal L. Schwartz published CGI::Prototype on CPAN yesterday. http://search.cpan.org/~merlyn/CGI-Prototype-0.90/lib/CGI/Prototype.pm The more, the merrier I suppose... I just posted a short review, pointing out that it seems redundant to cgiapp. Gads, that was probably a knee-jerk reaction, but this kind of thing really ticks me off sometimes... hmm ... maybe this e-mail is a knee-jerk reaction, too. So I hereby disclaim flamebait! ;) Anyway, from my experience with Mark and the rest of the gang here at cgiapp, dfv, htmltmpl, and such, they are definitely open to patches and other contributions. Why does Randal see the need to splinter off another framework? Randal probably has some very valid points (though as Matthew points out, we lack any elaboration), but imo, that would be best served by improving cgiapp and not creating competition. I also call Shenanigans on anyone who claims to love a clean MVC implementation and resorts to putting logic in templates, but that's my own axe to grind. Ok, thanks for letting me vent ... peace out. :) Jason - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
