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

[Colm O'Gairbhith]

Hi Ron,

Thanks for the detailed reply and advice ! As you said, I'll be doing some
thinking about all that. I guess my offer of payment was to allow me to
kickstart the dev without the guilt of asking for someone's precious time
for free.
I guess I'll start on the simplest CGI::App demo's, get my head around that
and then see how it goes.

Thanks / Colm


On Wed, May 11, 2011 at 12:29 AM, Ron Savage <ron at savage.net.au> wrote:

> 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
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
>


-- 

-- 
Carbon Tracking Ltd.
http://www.carbontracking.com
Telephone : +353 87 629 5679