John:Thanks for chiming in here. I hope that you enjoyed the talk I gave at Toronto.pm a few months ago on this topic and that it inspired you to come out for some more. :-)
Excellent point. However (as a one time publisher! and sometime tech writer) it is necessary to be very clear as to what the authors perceive as the mainstream of application framework being documented.
Sorry... I don't quite follow. Could you unwrap the latter part of this point?
Somebody earlier mentioned the framework you proposed at Toronto.pm Richard (I was the new face in the crowd that night) but a framework such as yours should not be seen as any sort of alternative - it is an example of how to build upon the basic infrastructure of CGI::A.
Oh, entirely! CGI::Application does a crucial job, and does it well, but it is not sufficient for a web/database application development toolkit. The kinds of problems I (and so many other people) solved are common to the domain, and it's important to appreciate how to bundle all the other pieces together with CGI::Application in order to get some real work done.
I see CGI::Application as the core of a controller, per the model-view-controller (MVC) programming paradigm.
Class::DBI is a good candidate for the "(data) model" portion (but not the only candidate!). [ Hand-rolled SQL strings and interaction view the plain vanilla DBI is *NOT* a good candidate! We would all be doing a great service to the world if we can help things move beyond this kind of programming. Vanilla DBI is okay for small, simple programming and/or database interaction that requires extreme speed. But for anything at all complicated, a higher level of abstration is needed. ]
HTML::Template is a good candidate for the "view" (but not the only candidate!). [ "print" statements and here-documents are *NOT* good candidates. ]
Then, you've got to throw in the things that are particular to web programming:
* Sessioning * Form field validation * HTTP header handling, incl. cookies * file uploads* "breaking up" returns of queries so that only 20 matches are displayed per page
* etc.CGI::Application is great, but it is only part of a complete framework for web application development. [ IMHO, one of the things that is so good about CGI::Application is how easily it allows the composition of these other technologies in order to create such a framework. ]
Obviously! It is hard to sell the attractions of any one environment without a realistic comparison.
In addition to this, it is helpful to use other examples of web application development frameworks in order to help other people understand the levels of abstraction / conceptual chunking that are involved in web development frameworks. Too often have I heard people say things like "PHP is easier to work with than mod_perl". What?!? YOU'RE COMPARING APPLES & GRAPEFRUITS, YOU MORONS! With a comparison section, someone who is familiar with (e.g.) PHP can be told what portion of the problem domain X_RANDOM_CGI_APPLICATION_BASED_FRAMEWORK addresses as compared to (e.g.) PHP, and they'll hopefully be able to understand all aspects of the problem domain better, using their existing understanding to bootstrap.
Hmmmm - titles can have a huge impact on how writers think. Jesse has been very careful to keep the vision for CGI::A clear, let it not be cluttered with application or even author specific code, but keep it clean, clear and a wonderful foundation on which anybody can build. Then the title should reflect that, as should the statement of editorial direction "CGI::A - a sure foundation for flexible Application farmeworks".
Right. I guess the thing that has to be considered is: what is the focus of the book? Two possibilities:
1.) A technical manual for a technology (CGI::Application) -- c.f. "Writing Apache Modules with Perl and C", "Practical mod_perl"
2.) A book that shows how a particular technology (CGI::Application) addresses a problem domain (writing complicated, useful web applications).
My contention is that (2.) is the way to go. Consider...* there are less people in the world who care about "hacking on CGI::Application" than there are who are interested in doing web application development
* for those who do care about "CGI::Application hacking", the existing CGI::Application docs cover the technology well, and what's left can be covered through the mailing list.
* what the existing docs don't well cover is the "gestault" of how to use CGI::Application in creating real, large CGI applications! (This is currently somewhat in the "best practices" web site, and somewhat in the minds of all the people who use it, and use it seriously.)
* any documentation of how to cover that gestault is very quickly going to start pulling in a bunch of other Perl modules (e.g. CGI::Session, HTML::Template, TT, Class::DBI, Tangram, Data::FormValidator, CGI::Application::ValidateRM)
It feels & sounds like a lot of people are independently coming to this kind of conclusion in their own programming work. (E.g. CheesePizza, CGI::Framework, Apache::PageKit, my own ramblings.) I know that I'd be lost in my own work without CGI::Application, but equally lost if that's ALL I had at my disposal.
VOLUNTEER: I have about thirty years of experience at technical writing and reviewing, pretty much all of it in academic and military research. But I would love to be involved as a reviewer/code tester for a project like this. Keep me in mind please :)
Sounds very cool. :-) I have no doubt you'll be asked to make good on the offer -- every hand makes the work better.
Cheers,
Richard
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.