[cgiapp] Anyone willing to give a paid guided tour to CGI::Application ??

[Ron Savage]

Hi Colm

There's no need to pay :-). Just post your questions to the list.

I hope you realize there is no one-true-method, but rather people have
their own ways of doing things, even if the end result of these
differences is not visible to the client.

As for CGI::Application, I personally find it marvellous for such apps.

I have a few suggestions (although you may need deeper understanding
before the point of these becomes obvious):

o Use CGI::Application::Dispatch. (I'll leave all 'why?'s to later
posts.)

o Avoid all, repeat all, unnecessary complication until you get
up-to-speed. In particular I'm referring to adding attributes to the
names of sub to indicate run modes. Quite possibly you'll get exactly
the opposite advice from other list members :-). Such is life! The
problem with all such mechanisms is the magical, action-at-a-distance
effect, which I feel should be adopted, if ever, only after all the
basics are understood.

o Think twice about all the plugins. A CPAN search of
CGI::Application::Plugin will return an amazing array of such code. I
personally use none of them any more, after I realized they added a
layer (wrapper) around the original code such that I felt distanced from
that code without any corresponding benefit.

o Be aware there are several ways to develop such app, using CGI::App:

1) Write it from scratch. Obviously we all start off this way, until our
understanding of the process and pre-existing code allows us to pick and
choose add-ons.

2) Adopt a package which tries to do everything for you. Some people
will embrace such a framework, while others will feel it's too
constraining. Jifty comes to mind here. Obviously with names like that
finding them on CPAN is a PITA, but it may well suit you. I don't go
that way myself.

3) Adopt a package which is a pre-existing, complete, app. I've uploaded
several to CPAN. In this case you studying working code /before/ writing
your own. Note: All such apps would (or should) have a config file
wherein you specify db connection params, default URLs, etc. My policy
is to always use such a file, specifically so you can edit it without
editing source code.

4) [This one's basically the same as (3)]. Give us a Perl module name to
work with, eg Killer::App, and I'll run my unreleased code generator
which will crank out a complete, running, search engine with a tiny db.
Of course, installing that and studying it will be the same as
installing an app from CPAN.

Whatever you do (perhaps all of these), just ask for help.

o At a more general level, I'd strongly advise (you may know all this
already) using App::perlbrew
http://search.cpan.org/~gugod/App-perlbrew-0.20/ to install your own
Perl, and then App::cpanminus
http://search.cpan.org/~miyagawa/App-cpanminus-1.4004/

This gives you your own copy of Perl, so you can install any module
without affecting the system Perl and other users.

This might at first seem unnecessary of indirect, but it does allow you
to delete manually unwanted modules, or versions, and it also allows you
to set the write bit and insert prints etc into working code to see
what's happening. These are ideally no things we want to do, but are on
rare occasions required (to fix you own bugs, normally).

For a db, use whatever you're familiar with, or DBD::SQLite.

Lastly, the definitive dev environment is plack
http://search.cpan.org/~miyagawa/Plack-0.9978/

For prod, use the optimized version called Starman
http://search.cpan.org/~miyagawa/Starman-0.2010/

My policy is to ship all apps with a straight CGI app and one which uses
plack/starman. These always use CGI::Application::Dispatch.

I'll stop now, since I'm such I've triggered enough questions in your
mind for the moment.

Welcome aboard!

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622