I gave a presentation on O/R mappers including Class::DBI at OSCON two years ago. I'll brush it off and make it an article.

Perl web application framewokrs: CGI::Applicaiton, Maypole, CGI::Prototype, etc.

I'm giving a presentation on this at YAPC::NA and OSCON this year. I'll make it an article after the conference.

UPDATE: Incidentally, the enterprise perl book is called Perl Medic.

For a while I had been thinking of writing a meditation called "Perl books I'd like to see," but since you posted this one, I may as well add turn my meditation into a note to it.

I'd like to see someone start a whole series of Perl "cookbooks" devoted to whole modules and applications. For example, an entire book showing how to write a basic mail client in Perl, or a simple text editor, or a simple web browser, or a personal calendar/address book or an personal accounting program, or a basic mail-order website, or an internet forum like PM. Of course, these applications would not match the functionality and performance of existing open-source offerings. The point is rather to take an intermediate or advanced beginner through the process of crafting a full-blown application. This process involves many design decisions that are difficult to convey in the abstract.

One objection I have received to this idea is that the issues involved in designing such an application are not specific to Perl. That's certainly true, but the same could be said of most if not all the recipes in the Perl Cookbook. My point is that there is value to the non-expert in seeing the process of developing a full-blown application in concrete, spelled-out terms, such that design questions cannot be waved away with theoretical generalities. In a full-blown application, even a toy application like what I'm describing, tradeoffs must be examined and decisions made, and, at the end of the day, the thing has to perform.

That said, I think it would be essential to leave room for the reader to try things out on his/her own. It would be easy to include exercises such as "modify module X to add features Y and Z." The book could end with an extended discussions of ways in which the application may be enhanced, and maybe pushed beyond the level of a learning toy.

I realize that there are a lot of people programmers who do not need this type of book, but then again there are a lot of programmers who do not need books like Learning Perl, and who go straight for Programming Perl (if not the PODs). I think there'd be a sufficiently large audience for such a series.

I think this is a excellent++ idea! Personally, I learn much quicker from examples than from documentation and theory. I enjoy and consume theory but have a much easier time seeing ways to put the theory into practice by seeing and understanding how others have applied it.

While this is possible to do by 'studying the source Luke' it is much clearer, and quicker, for me if I can see and understand the rationale for why something was done rather than just seeing and exploring what was done.

Just my $.02

TheStudent

I'd like to see someone start a whole series of Perl "cookbooks" devoted to whole modules and applications.

You mean, besides me?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

By definition the applications I have in mind are bigger and/or described at a greater level of detail than could reasonably fit into a magazine article. By "greater level of detail" I mean full source code, in which every module, subroutine, and variable is described. I don't think there is anything like this in the market at the moment, in any language, but years ago I saw a book that described, at this level of detail, how to implement an RDBMS in C. The typical chapter described a module of the program: the specs, the important design options and tradeoffs that had to be considered, and finally the gory details of the implementation, function by function and struct by struct. One could think of it as the programming equivalent of a kit for the weekend hobbyist to build a working car or airplane, providing every nut and bolt for it, and a diagram of where each goes.

the lowliest monk

Have you gotten around to doing an article on PAR yet?

Couple of points about your list.

Perl Object-Relational mapping: Class:DBI

Class::DBI could probably fill the entire book, but that would do a disservice to the other great O/R frameworks out there. Not to mentions the fact that the subject of O/R mapping is a wide and varied topic which is as much theory as it is implementation.

That said, a Class::DBI book would be nice :)

Perl web application frameworks: CGI::Applicaiton, Maypole, CGI::Prototype, etc.

Don't forget about Catalyst, I have not tried it myself, but I have heard nothing but good things about it. I also think that this subject would not fit easily into one book, and separate books per-framework would probably be best.

How to develop, test and maintain large perl projects.

I agree very much on this one. While merlyns book is great, it only covers so much. I would love to see a good book which really delves into large scale design/development/testing/maintainence in any language for that matter.

perl for application testing: WWW::Mechanize, Win32::IE::Mechanize

IIRC chromatic just collaborating on a book on perl testing. I would guess that it has this type of stuff in it.

Now that it was mentioned could anyone tell me some reason why would I want to dumb down my relational database to an object store? I don't know, maybe it feels good to those that only feel comfortable in Perl to be shielded from SQL, but I find this a little silly. Why would I want to use Class::DBI?

Jenda


XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

Class::DBI is to a database what DreamWeaver is to HTML.

You can use it as an object store (or do web page layout), or use it to avoid having to write all that SQL (or HTML) code and just fiddle with the code when the tool doesn't do what you wanted it to.

It's about productivity.

You still need to know what you're doing though. A database is a not-very-black box, and web design is only partly about visual design.

/J

Why would I want to use Class::DBI?

I use it for the times when the SQL that I'd be writing is so pointlessly simple and repetitive that it's a better use of my time to get the computer to write it for me. There are enough hooks in Class::DBI for me to write the SQL that I need to write for efficiency reasons so what I gain on the swings I also gain on the roundabouts.

Do I use it all of the time? Hell no. Sometimes the way I'll be using my data is so far away from the Class::DBI view of the world that I'd spend more time getting around it than using it. For simple CRUD applications however it's a boon.

IMHO of course :-)

perl for application testing: WWW::Mechanize, Win32::IE::Mechanize

I'm hoping the upcoming Perl Testing Developer's Notebook will cover some of this.

There's also what's likely to be a very good Ruby testing book being writen by Brian Marick for the Pragmatic Bookshelf folk. I'd imagine you will be able to take a lot of this over to the Perl world quite easily.

<plug>

Yes, Perl Testing: A Developer's Notebook will cover WWW::Mechanize, as well as other useful modules for testing web applications. It'll include examples of how to organize and run your tests, as well as how to develop tests for common scenerios, whatever your large project may be.

(Win32::IE::Mechanize, unfortunately, didn't make it in.)

</plug>

-- Ian Langworth