Alternative to bad perl resources
Following the general feelings of the professional perl mongers on the list towards certain authors and script archives, I thought the perl mongers could build their own script recipebook on the net and provide secure but clear and simple and well explained example and instant cgi scripts as an alternative to Matt and other resources. Given that there are quite a few scripts out there, we could concentrate on having secure, well written and explain perl for key tasks like - search engine, forum, shopping cart and checkout (alternatives for mason, tt, etc). This would be something good to point beginners at - particularly if ORA give it some support. A. -- A HREF = "http://termisoc.org/~betty" Betty @ termisoc.org /A "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me)
Re: Alternative to bad perl resources
the best way to get this started, is simply to do it and then others will lend in their support, just put up a webpage with the first few candidates and let others comment just my 2 cents, greg * Aaron Trevena ([EMAIL PROTECTED]) wrote: Following the general feelings of the professional perl mongers on the list towards certain authors and script archives, I thought the perl mongers could build their own script recipebook on the net and provide secure but clear and simple and well explained example and instant cgi scripts as an alternative to Matt and other resources. Given that there are quite a few scripts out there, we could concentrate on having secure, well written and explain perl for key tasks like - search engine, forum, shopping cart and checkout (alternatives for mason, tt, etc). This would be something good to point beginners at - particularly if ORA give it some support. A. -- A HREF = "http://termisoc.org/~betty" Betty @ termisoc.org /A "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me) -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: Alternative to bad perl resources
On Mon, 19 Feb 2001, Greg McCarroll wrote: the best way to get this started, is simply to do it and then others will lend in their support, just put up a webpage with the first few candidates and let others comment That would make the large assumption that my perl is a good example. I hope that DragonForum (soon to be released, watch this space) will make a good alternative to wwwthreads and ubbs, but although it is now cleaner and template based it isn't really an example of good perl. Ditto the search engine based on the DDJ one. Hopefully I can bring it up to scratch as it is fairly simple. Of course I could put them up with a disclaimer saying that they aren't GOOD perl but are cleaner and easier to understand than most of the scripts on the web. A. -- A HREF = "http://termisoc.org/~betty" Betty @ termisoc.org /A "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me)
Re: Alternative to bad perl resources
Aaron Trevena [EMAIL PROTECTED] writes: That would make the large assumption that my perl is a good example. I hope that DragonForum (soon to be released, watch this space) will make a good alternative to wwwthreads and ubbs, but although it is now cleaner and template based it isn't really an example of good perl. I'm using mwf, and someone hereabouts threatened to TTify it, I think. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: Alternative to bad perl resources
On 19 Feb 2001, Dave Hodgkinson wrote: Aaron Trevena [EMAIL PROTECTED] writes: That would make the large assumption that my perl is a good example. I hope that DragonForum (soon to be released, watch this space) will make a good alternative to wwwthreads and ubbs, but although it is now cleaner and template based it isn't really an example of good perl. I'm using mwf, and someone hereabouts threatened to TTify it, I think. yes - that were me. It is a quiet horrid job. I am splitting the thing into 3 layers and the templates. so far I have managed to greatly simplify things like forum_show.pl and make it much cleaner by removing a lot of presentation related code that really should be in the templates rather than embedded in perl code. It will take more work to make it a good example of code, in fact that may not even be possible if I want to keep it compatible (which I do) so that you can use the same DB and plugins. I estimate it will take 3 more weeks before I can release it. (because I have very little spare time at the mo). A. -- A HREF = "http://termisoc.org/~betty" Betty @ termisoc.org /A "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me)
Re: Alternative to bad perl resources
Aaron Trevena [EMAIL PROTECTED] writes: On 19 Feb 2001, Dave Hodgkinson wrote: Aaron Trevena [EMAIL PROTECTED] writes: That would make the large assumption that my perl is a good example. I hope that DragonForum (soon to be released, watch this space) will make a good alternative to wwwthreads and ubbs, but although it is now cleaner and template based it isn't really an example of good perl. I'm using mwf, and someone hereabouts threatened to TTify it, I think. yes - that were me. It is a quiet horrid job. I am splitting the thing into 3 layers and the templates. so far I have managed to greatly simplify things like forum_show.pl and make it much cleaner by removing a lot of presentation related code that really should be in the templates rather than embedded in perl code. Balls to that, sounds like too much work. I can live with the inner sucky stuff, but Stage 1 surely is to have an outer template you can stick all your site-wide branding and stuff in? Dave // I picked two: laziness and impatience... -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: Alternative to bad perl resources
Aaron Trevena [EMAIL PROTECTED] writes: It is indeed, but this tends to require a fair amount of rewriting or be a horrible horrible kludge. Hmmm...there was one subroutine that did all the sandwich things...oh, no two. printHeader and printFooter. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
Re: Alternative to bad perl resources
On 19 Feb 2001, Dave Hodgkinson wrote: Aaron Trevena [EMAIL PROTECTED] writes: It is indeed, but this tends to require a fair amount of rewriting or be a horrible horrible kludge. Hmmm...there was one subroutine that did all the sandwich things...oh, no two. printHeader and printFooter. I done those. easy. but for it to work you want to be able to design the table layouts and stuff otherwise you are stuck with a horrid mix of mw's embedded html and templates. A. -- A HREF = "http://termisoc.org/~betty" Betty @ termisoc.org /A "As a youngster Fred fought sea battles on the village pond using a complex system of signals he devised that was later adopted by the Royal Navy. " (this email has nothing to do with any organisation except me)
Re: Alternative to bad perl resources
* at 19/02 13:34 + Steve Mynott said: Tony Bowden [EMAIL PROTECTED] writes: Surely part of the reason that so much bad code gains so much popularity is that bad coders tend to think their code is good, so don't mind publicising it and shouting about it lots. Good coders, on the other hand, think that their code is always bad, so are reluctant to do much with it. But their "bad" is usually much better than others "good" ... This is very true. Also code beauty is in the eye of the beholder and is subjective. Also badly written code can be "good" in the sense of being useful. ah, we have so much of that :( every time it needs hac^H^H^Hextended i try and clean it up but given i never have the time to start from sratch it's an uphill struggle. We, as programmers, mean internal design when we say "good" whereas users refer to software as "good" because it has a simple UI, is useful and solves some problems without creating many new ones. Of course good internal design probably tends to correspond to a certain extent to good software, since it should be easier to extend when new features are required and should be less buggy. and also, well thought out software design should reflect in better useability. if the code is a maze of hacks and kludges then it's all the harder to hide that behind a clean front end. the fact that UI design seems to be a much ignored skill doesn't help. struan
magic use
Jo was talking on IRC today and made me think about packages. Imagine if you will the following situation ... you have Country.pm which implements the general functions with default implementation for each country you have special cases such as Country::France which say for example they do things differently so you want to do use Country::Germany and just use the default subs from Country.pm in a pretty much trivial class now you would have to implement these trivial 4 line packages for each trivial country. i wondered how you could do it better. i'm sure this is a feature that is in CPAN/Perl somewhere, but just in case it isn't please witness Muse.pm a 5 minute (and probably buggy) implementation of muse (magic use) that takes care of this problem. i'm sure its already in CPAN but i havent programmed for ages, so couldnt be bothered to think about it Greg p.s. i dont recommend ever using this code in production -- Greg McCarroll http://www.mccarroll.uklinux.net Country.pm Muse.pm test.pl
