- Different methods of handling the same task can coexist easily. Different versions of code may be due to approaches that offer specific advantages in certain situations, or may designed to work in different environments, such as CGI vs. mod_perl or HTML::Template vs. Template Toolkit, or database vs. non-database. Or, they could just be to contrast different styles of code.
- The "glue" code which ties the various tasks in a full application can be avoided, allowing a more pure focus on a specific task, without distractions.
- The individual samples of code would be much smaller than a full application, and less intimidating to read. Also, topics which the reader doesn't care about can be skipped easily.
- Having code samples that are reasonably self-sufficient (except for maybe a skeletal application to provide the context) and as generic as possible, coders could use them more easily and directly in their own code, versus extracting it from a full application and adapting it.
- The project can progress quickly, as individual coders can submit samples to the various topics, without the work of integrating it into a larger project.
I would find a repository of code samples immensely useful, as it would save me from reinventing the wheel every time I need to do something new.
At 04:16 PM 5/16/2003 -0400, Steve Comrie wrote:
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. 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. 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.
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/suppressed/ To unsubscribe, e-mail: suppressed For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.