Re: [cgiapp] Re: Wiki as "Best practices" of CGI::App

[Peter Masiar <suppressed>]

Quoting Steve Comrie <suppressed>:

> I'm in much the same boat as Mark on this issue. I have a slew of projects
> using CGI::App in various stages of development that I don't imagine I'd be
> able to invest much time in starting another project from scratch.

FAQ: How to find a good contractor to repair your house?
A: If he is too busy working for other clients, no time to work for you. ;-)

I understand this point. I am repairing a condo. ;-)
I was just thinking that there was interest to build a wiki before,
and I discouraged it. :(

> 
> One of the earliest problems that I foresee are people that have been using
> CGI::App for a long (such as Mark,  myself, and numerous others on the list)
> having differing view points on exactly what the best practice for a certain
> operation is. i.e. Setting a cookie, Reading a config file, storing session
> information, logging in a user, querying a database, sorting database
> records, etc, etc. The discussion alone on each of these points could grind
> development of any useful application to a snail's pace. Too many chief's,
> not enough Indians.

Absolutely.
There never is one single "always correct" way to handle anything.

> If people really want to get started on the topic of best practice scenarios
> using CGI::App I'd suggest we first create a comprehensive list of scenarios
> for which we would like to catalog the best practices for. Once we have a
> list, people can start to submit descriptions, suggestions or code relevant
> to each scenario, and then we can begin to discuss pros, cons, benefits,
> draw-backs of each practice.
> 
> In the end we may not necessarily come up with one 'best' practice for each
> scenario, but instead have a list of viable solutions which can be used by a
> programmer based on the requirements & constraints of the system they are
> planning to develop.
> 
> The outcome of collectively developing best practice guidelines in this
> manner (IMHO) would result in a much more accessible wealth of information,
> techniques and relevant discussion instead of burying the best practices in
> code. New, intermediate & advanced CGI::App developers would all benefit
> both in accessing the information and ease of contribution to individual
> topics.
> 
> Look at the list of features that Mark mentioned he would like to add to his
> project:
> 
> >> - Switch to CGI::Session for session handling
> >> - use Data::FormValidators new validation features
> >> - use new OO image upload module (recently mentioned here)
> >> - better MVC design
> >> - possibly use mod_auth_pg
> >> - better error handling / logging, possibly with Log::Log4Perl
> >> - better testing practices, using Test::More, WWW::Mechanize,
> >>    Test::DatabaseRow...and friends.
> 
> Every single item on that list merits a discussion on best practice
> guildlines to successful achieve them. And I'm sure that from these
> discussions and guidelines, we would start to see emerging concepts that
> could then be turned into modules to assist in the seamless development of
> CGI::App modules ... CGI::App::Session, CGI::App::Cookie, CGI::App::Test,
> CGI::App::Config. The list could be endless.
> 

Absolutely. We need first to figure out what the problem is,
and only then start solving it.

Some experts from the list will contribute code, some just advice,
and still others will just learn something from reading discussions.

But untill we have real guru chief designer willing to start cooking, 
... we are not cooking. ;-)

Let me rephrase my question:

Do we have a guru in the list, willing to be chief designer in creating
CGI::App based wiki, which could be considered a good example of CGI::App?


-- 
Peter Masiar, suppressed, (203) 764-8131
Yale Center for Medical Informatics (YCMI), http://ycmi.med.yale.edu


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed