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 <[email protected]> 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://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > > > -- -- Carbon Tracking Ltd. http://www.carbontracking.com Telephone : +353 87 629 5679 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
