Quoting Chad Redman <suppressed>: > I feel this is the most useful way to build up "best practices" > documentation. Each specific topic -- authentication, form validation, etc. > -- can be dealt with individually, which would have a number of benefits: I agree. To get somewhere we need to split problem to parts and deal with each part separately (making sure we can integrate later ;-) ). Mark sugested couple of quasi-independent areas where some consenzus could be worked on, as he is working on his Cascade system. Steve Comrie rightly noticed that to define "best" we need to know scenario. My original idea was to define scenarios for using a non-database wiki. Apparently, list wants to work in parallel also on other aspects of "best practices", like databases, which is fine with me. I assume we decided to work on knowledgebase of best practices of using CGI::Application - or at least play with the idea more seriously. ;-) So, what we should do next? How to create "a comprehensive list of scenarios", as Steve suggests? Of course it's possible to start shooting emails left and right, trying to keep subject relevant, and quote some context so re-reading archives some time from now will make more sense. But I personaly shrug at the idea :-( I assume most people do have some exposure how to use a wiki to this kind of collaborative project - or at least is willing to try. (see subject of this message ;-) ) Brad Adkins kindly proposed to set up and host a wiki for this project. We need to distinguish wiki as knowledge repository (like hosted by Brad), and new wiki engine being build as example for best practices (hosted possibly somewhere else). I'll call it NEW wiki 'Knowledge wiki' needs to be up and running *before* we can start pouring ideas/solutions/code in, 'example wiki engine - NEW wiki' will be somehow functional only later, and contens of the pages stored in it will be just a test messages, until deemed stable. However, later when stable, we can swich wiki engines, and use our NEW wiki engine to handle best practices knowledge repository to test it better. "Knowledge wiki could (and will) of course store all ideas about best CGI::App practices, not only related to development related to NEW wiki. With so many wiki engines, where to start? Which existing stable wiki engine to use as knowledge repository, and which promising emerging one as starting point of development of NEW wiki? Brad suggested to use UseMod wiki as knowledge repository. Ron Pero suggested to use OO-based Kwiki as starting point. Kate L Pugh (in private email to me) suggested to look at Max Maischein's CGI::Wiki::Simple package, claiming it is CGI::App based. I (Peter Masiar) have good experience with Twiki (properly spelled as TWiki). To start, we need just to decide which wiki to use as repository. What criteria are important when selecting wiki for knowledge repository? Many wikis do not care about user authentication and version control. But Twiki has both, and if somebody by mistake or maliciously deleted/destroyed a page, it's rather easy to restore it. Twiki has also powerfull categorization system, any page could belong to multiple categories, each with multiple values, which are searchable. Twiki developers build whole workflow system to track bugs and features using this feature, which we can use, too. Twiki is able to sent emails with links to pages changed recently, to person relying on email's INBOX can see what is going on, and participate in some discussions, while ignore others. This email could be sent to this list, too, so even developers not subscribed initially could contribute, if interested. In a sentence, Twiki is most powerfull perl wiki engine and worth "stealing from". And as I noted there are Twiki developers thinking of creating OO fork. Twiki is far from perfect, of course. Is hard to install, markup language sometimes is not as intuitive as it could be, and terminology is not user friendly and sometimes almost misleading. But is not bad at all. Solving this Twiki shortcomings could be also part of the fun ;-) Twiki as repository of course is a suggestion - we could use as a repository some engine which we will use as starting point. Which way to go now? -- Peter Masiar, suppressed, (203) 764-8131 Yale Center for Medical Informatics (YCMI), http://ycmi.med.yale.edu I am not a lawyer. My ideas are NOT binding for University. In doubt, Yale policy right: http://www.yale.edu/policy/itaup.html --------------------------------------------------------------------- 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.