From jarich at perltraining.com.au Fri Nov 1 00:38:54 2002 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Wed Aug 4 00:02:45 2004 Subject: Perl Meetup day In-Reply-To: <3DC1C710.4090004@StrategicData.com.au> Message-ID: On Fri, 1 Nov 2002, Adam Clarke wrote: > My understanding is that Gin has a reputation for producing exactly the > opposite emotion :) Well there could be that, but I've never seen anything nasty happen at the Gin Palace. It does get quite crowded though. The Gin Palace is a pretty wierd place to get to. It's on a laneway between Lt Collins and Bourke streets. You wander down and get to a place with a sign "gp" out the front and no other indications of what happens inside. It passes a lot of people's minds that it could be a brothel. There's a tiny plaque somewhere that says "Gin Palace" but when I read that I wasn't thinking "Gin" as in alcohol, perhaps as a name... It's way too noisy and crowded on Friday and Saturdays nights to be enjoyable in my opinion. Thursday should be good (so long as we can all make it to work the next morning.) Jacinta -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +613 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact@perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au | From jhoward at fastmail.fm Fri Nov 1 01:31:17 2002 From: jhoward at fastmail.fm (Jeremy Howard) Date: Wed Aug 4 00:02:45 2004 Subject: Perl Meetup day Message-ID: <20021101073117.B2AF450A7F6@server5.fastmail.fm> On Fri, 1 Nov 2002 17:38:54 +1100 (EST), "Jacinta Richardson" said: > The Gin Palace is a pretty wierd place to get to. It's on a laneway > between Lt Collins and Bourke streets. You wander down and get to a > place > with a sign "gp" out the front and no other indications of what happens > inside. It passes a lot of people's minds that it could be a brothel. > There's a tiny plaque somewhere that says "Gin Palace" but when I read > that I wasn't thinking "Gin" as in alcohol, perhaps as a name... > For truely weird, be sure to check out The Croft Institute... > It's way too noisy and crowded on Friday and Saturdays nights to be > enjoyable in my opinion. Thursday should be good (so long as we can all > make it to work the next morning.) > Agreed--what's the fun of a meet if we can't talk? -- Jeremy Howard jhoward@fastmail.fm From scottp at dd.com.au Sat Nov 2 23:29:03 2002 From: scottp at dd.com.au (Scott Penrose) Date: Wed Aug 4 00:02:45 2004 Subject: CGI Development - Multiple Entry or Dispatch Message-ID: <29D4C7C6-EEED-11D6-B7F5-003065B58CF8@dd.com.au> Hey Dudes, When developing CGI, wether via web application style (ala Mod Perl) or individual (ala CGI) you get the choice of having multiple entry points or a dispatch. Most programs never go for complete multiple entry. Usually you will get a CGI script to view, edit and save an entry of some type (eg: in a database). So even multiple entry points have at least some dispatch. An alternative is to have a single entry point for an application, where you have a dispatch (usually around the rest of the PATH) to decide if you want to list vs edit vs save etc. Do people have an opinion on what is the better way and why? What would you recommend if you were developing all over again ? Scott -- Scott Penrose Anthropomorphic Personification Expert http://search.cpan.org/search?author=SCOTT scott@cpan.org Dismaimer: While every attempt has been made to make sure that this email only contains zeros and ones, there has been no effort made to guarantee the quantity or the order. From scottp at dd.com.au Sun Nov 3 17:01:07 2002 From: scottp at dd.com.au (Scott Penrose) Date: Wed Aug 4 00:02:45 2004 Subject: CGI Development - Multiple Entry or Dispatch In-Reply-To: <3DC61BD1.4070500@iprimus.com.au> Message-ID: <22B2F6B6-EF80-11D6-B7F5-003065B58CF8@dd.com.au> On Monday, Nov 4, 2002, at 18:03 Australia/Melbourne, David Dick wrote: > can you give a short code example of what you mean by multiple entry > and dispatch methods? dispatch.cgi ------------ use MyImplementation; my $m = MyImplementation-new(); if ($ENV{PATH_INFO} eq "") { $m->view; } elsif ($ENV{PATH_INFO} eq "edit") { $m->edit; } elsif ($ENV{PATH_INFO} eq "save") { $m->save; } else { $m->error; } OR, multiple methods view.cgi -------- use MyImplementation; MyImplementation-new()->view(); edit.cgi -------- use MyImplementation; MyImplementation-new()->edit(); save.cgi -------- use MyImplementation; MyImplementation-new()->save(); Of course in the multiple version, you generally actually implement the code there, rather than just calling another method. The advantages of single point of entry are: - Single location of code - Single point for setting up, database handles, config etc - Easier to make mod perl The advantages of multiple entry points are: - Easier to implement - Faster to load (less code to compile) - Getting the web server to do what you would have to do manually. - More flexibility on installation (just web server config changes) Scott > Scott Penrose wrote: > >> Hey Dudes, >> >> When developing CGI, wether via web application style (ala Mod Perl) >> or individual (ala CGI) you get the choice of having multiple entry >> points or a dispatch. >> >> Most programs never go for complete multiple entry. Usually you will >> get a CGI script to view, edit and save an entry of some type (eg: in >> a database). So even multiple entry points have at least some >> dispatch. >> >> An alternative is to have a single entry point for an application, >> where you have a dispatch (usually around the rest of the PATH) to >> decide if you want to list vs edit vs save etc. >> >> Do people have an opinion on what is the better way and why? What >> would you recommend if you were developing all over again ? >> >> Scott > > > > > -- Scott Penrose Welcome to the Digital Dimension http://www.dd.com.au/ scottp@dd.com.au Dismaimer: Contents of this mail and signature are bound to change randomly. Whilst every attempt has been made to control said randomness, the author wishes to remain blameless for the number of eggs that damn chicken laid. Oh and I don't want to hear about butterflies either. From pjf at perltraining.com.au Sun Nov 3 21:51:24 2002 From: pjf at perltraining.com.au (Paul Fenwick) Date: Wed Aug 4 00:02:45 2004 Subject: CGI Development - Multiple Entry or Dispatch In-Reply-To: <22B2F6B6-EF80-11D6-B7F5-003065B58CF8@dd.com.au> References: <3DC61BD1.4070500@iprimus.com.au> <22B2F6B6-EF80-11D6-B7F5-003065B58CF8@dd.com.au> Message-ID: <20021104035124.GC25433@mukc.org.au> G'day Scotty / Melb.PM, Golly, my answer to this question is a great big "it depends". If the project involves mod_perl or CGI::Fast, then the dispatch mechansim as some obvious advantages. Modules only need to be loaded once, a single database connection can be used, and data can be cached between requests. Of course, if your various functions have little overlap with each other, then you may only have a negligible speed saving from using dispatch vs multiple methods. Outside of a mod_perl/fastcgi environment, dispatch becomes slower as there's more code to load in and parse. At the end of the day, unless one method gives you a *significant* saving or advantage over the other, then I can't say I have an opinion either way. I've personally used both methodologies, and continue to do so. Usually I'm aiming for whichever approach gives the most clean, maintainable, and efficient code. Most of the time I use both methods -- dispatch for closely related features, and multiple entry for widely separated ones. All the best, Paul -- Paul Fenwick | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia | Fax: +61 3 9354 2681 From joshua at roughtrade.net Sun Nov 3 23:26:00 2002 From: joshua at roughtrade.net (Joshua Goodall) Date: Wed Aug 4 00:02:45 2004 Subject: CGI Development - Multiple Entry or Dispatch In-Reply-To: <22B2F6B6-EF80-11D6-B7F5-003065B58CF8@dd.com.au> References: <3DC61BD1.4070500@iprimus.com.au> <22B2F6B6-EF80-11D6-B7F5-003065B58CF8@dd.com.au> Message-ID: <20021104052600.GE16670@roughtrade.net> On Mon, Nov 04, 2002 at 10:01:07AM +1100, Scott Penrose wrote: > dispatch.cgi > ------------ > > use MyImplementation; > my $m = MyImplementation-new(); > > if ($ENV{PATH_INFO} eq "") { > $m->view; > } elsif ($ENV{PATH_INFO} eq "edit") { > $m->edit; > } elsif ($ENV{PATH_INFO} eq "save") { > $m->save; > } else { > $m->error; > } This seems more maintainable to me. You could even abstract it (validation notwithstanding): use MyImplementation; use CGI; my $m = new MyImplementation; my $q = new CGI; my $p = $ENV{PATH_INFO}; $m->$p($q) if $m->publicmethod($p); This turns the request into a facade for invocation of a method on a visited object. OO pattern freaks please note :) This is not unlike the container model of a J2EE server, although without any of the sophistication (resource/instance pooling etc). If MyImplementation is autosplit, then neither approach needs much compilation. The dispatch model also allows MyImplementation to be a completely remote process. In the multiple methods model, you're constrained to only implementing remote methods known in advance. Not many people need such separation, of course. I think ultimately only very large or complex OO systems benefit (in maintainability) from strict pattern usage. Everything else seems to fall into the category of "whatever seems most appropriate at the time". Joshua From david_dick at iprimus.com.au Mon Nov 4 12:49:30 2002 From: david_dick at iprimus.com.au (David Dick) Date: Wed Aug 4 00:02:45 2004 Subject: CGI Development - Multiple Entry or Dispatch In-Reply-To: <3DC61BD1.4070500@iprimus.com.au> References: <3DC61BD1.4070500@iprimus.com.au> <22B2F6B6-EF80-11D6-B7F5-003065B58CF8@dd.com.au> <20021104052600.GE16670@roughtrade.net> Message-ID: <3DC6C13A.7050506@iprimus.com.au> Joshua Goodall wrote: >On Mon, Nov 04, 2002 at 10:01:07AM +1100, Scott Penrose wrote: > > >>dispatch.cgi >>------------ >> >> use MyImplementation; >> my $m = MyImplementation-new(); >> >> if ($ENV{PATH_INFO} eq "") { >> $m->view; >> } elsif ($ENV{PATH_INFO} eq "edit") { >> $m->edit; >> } elsif ($ENV{PATH_INFO} eq "save") { >> $m->save; >> } else { >> $m->error; >> } >> >> > >This seems more maintainable to me. You could even abstract it >(validation notwithstanding): > > use MyImplementation; > use CGI; > > my $m = new MyImplementation; > my $q = new CGI; > my $p = $ENV{PATH_INFO}; > > $m->$p($q) if $m->publicmethod($p); > >This turns the request into a facade for invocation of a method >on a visited object. OO pattern freaks please note :) > >This is not unlike the container model of a J2EE server, although >without any of the sophistication (resource/instance pooling etc). > where does J2EE implement this sort of stuff? I always imagined that instance pooling would be handled by a some sort of proxy thingy inbetween the script and MyImplementation method, like my $m = proxy_new MyImplementation; to allow for the pooling to be used by cron jobs for example. Or am i completely off the wall here? >If MyImplementation is autosplit, then neither approach needs much >compilation. > >The dispatch model also allows MyImplementation to be a completely >remote process. In the multiple methods model, you're constrained >to only implementing remote methods known in advance. > i would argue that can be a strength of multiple methods. It forces a private vs public methods implementation, and stops a later developer from blowing a hole in the application by developing MyImplemention->admin_function() only to find out that without his/her knowledge, it's become a function available to anyone with a web browser. >Not many people need such separation, of course. I think ultimately >only very large or complex OO systems benefit (in maintainability) >from strict pattern usage. Everything else seems to fall into the >category of "whatever seems most appropriate at the time". > >Joshua > > > From david_dick at iprimus.com.au Mon Nov 4 13:02:02 2002 From: david_dick at iprimus.com.au (David Dick) Date: Wed Aug 4 00:02:45 2004 Subject: CGI Development - Multiple Entry or Dispatch In-Reply-To: <3DC61BD1.4070500@iprimus.com.au> References: <3DC61BD1.4070500@iprimus.com.au> <22B2F6B6-EF80-11D6-B7F5-003065B58CF8@dd.com.au> <20021104035124.GC25433@mukc.org.au> Message-ID: <3DC6C42A.1050407@iprimus.com.au> on a side note, how many people actually use 'real' PerlHandlers for their web applications and how many develop CGI scripts and smack 'em along with Apache::Registry? i just like using Apache::Registry because it lets me debug in a more controlled fashion and it's more portable (to what i don't know :)). Anyone prefer using the 'real' PerlHandlers? Paul Fenwick wrote: >G'day Scotty / Melb.PM, > > Golly, my answer to this question is a great big "it depends". >If the project involves mod_perl or CGI::Fast, then the dispatch >mechansim as some obvious advantages. Modules only need to be >loaded once, > i thought that mod_perl meant that regardless of how many times a module was used, it was only loaded once? >a single database connection can be used, > doesn't Apache::DBI type solutions solve this regardless of whether multiple entry/dispatch is being used? >and data >can be cached between requests. > don't understand this one either. sorry. :) could you give an example of why you can't cache with the multiple entry points? > > Of course, if your various functions have little overlap >with each other, then you may only have a negligible speed saving >from using dispatch vs multiple methods. Outside of a mod_perl/fastcgi >environment, dispatch becomes slower as there's more code to >load in and parse. > > At the end of the day, unless one method gives you a >*significant* saving or advantage over the other, then I can't >say I have an opinion either way. I've personally used both >methodologies, and continue to do so. Usually I'm aiming for >whichever approach gives the most clean, maintainable, and efficient >code. Most of the time I use both methods -- dispatch for >closely related features, and multiple entry for widely >separated ones. > > All the best, > > Paul > > > From joshua at roughtrade.net Mon Nov 4 06:26:29 2002 From: joshua at roughtrade.net (Joshua Goodall) Date: Wed Aug 4 00:02:45 2004 Subject: CGI Development - Multiple Entry or Dispatch In-Reply-To: <3DC6C13A.7050506@iprimus.com.au> References: <3DC61BD1.4070500@iprimus.com.au> <22B2F6B6-EF80-11D6-B7F5-003065B58CF8@dd.com.au> <20021104052600.GE16670@roughtrade.net> <3DC6C13A.7050506@iprimus.com.au> Message-ID: <20021104122629.GA426@roughtrade.net> On Mon, Nov 04, 2002 at 06:49:30PM +0000, David Dick wrote: > >This is not unlike the container model of a J2EE server, although > >without any of the sophistication (resource/instance pooling etc). > > > where does J2EE implement this sort of stuff? I always imagined that > instance pooling would be handled by a some sort of proxy thingy > inbetween the script and MyImplementation method, like > > my $m = proxy_new MyImplementation; > > to allow for the pooling to be used by cron jobs for example. Or am i > completely off the wall here? You're not at all, as far as I know; in particular I had in mind the life-cycle of a J2EE Session EJB. Although in J2EE, it's up to the container (a subsection of the application server) precisely when to instantiate for you, and it's typically abstracted through a directory service and an abstractfactory pattern. It's quite overblown outside of multi-tier applications. > i would argue that can be a strength of multiple methods. It forces a > private vs public methods implementation, and stops a later developer > from blowing a hole in the application by developing > MyImplemention->admin_function() only to find out that without his/her > knowledge, it's become a function available to anyone with a web browser. I think only a very naive implementation of the dispatch approach would allow such. E.g., all the sample code in this thread checked the allowedness of a method. J -- Joshua Goodall joshua@roughtrade.net "Your byte hit ratio is weak, old man" "If you cache me now, I will dump more core than you can possibly imagine" From david_dick at iprimus.com.au Tue Nov 5 02:59:32 2002 From: david_dick at iprimus.com.au (David Dick) Date: Wed Aug 4 00:02:45 2004 Subject: CGI Development - Multiple Entry or Dispatch In-Reply-To: <3DC61BD1.4070500@iprimus.com.au> References: <3DC61BD1.4070500@iprimus.com.au> <22B2F6B6-EF80-11D6-B7F5-003065B58CF8@dd.com.au> <20021104052600.GE16670@roughtrade.net> <3DC6C13A.7050506@iprimus.com.au> <20021104122629.GA426@roughtrade.net> Message-ID: <3DC78874.5070605@iprimus.com.au> Joshua Goodall wrote: >On Mon, Nov 04, 2002 at 06:49:30PM +0000, David Dick wrote: > > >>>This is not unlike the container model of a J2EE server, although >>>without any of the sophistication (resource/instance pooling etc). >>> >>> >>> >>where does J2EE implement this sort of stuff? I always imagined that >>instance pooling would be handled by a some sort of proxy thingy >>inbetween the script and MyImplementation method, like >> >>my $m = proxy_new MyImplementation; >> >>to allow for the pooling to be used by cron jobs for example. Or am i >>completely off the wall here? >> >> > >You're not at all, as far as I know; in particular I had in mind >the life-cycle of a J2EE Session EJB. Although in J2EE, it's up to >the container (a subsection of the application server) precisely when to >instantiate for you, and it's typically abstracted through a directory >service and an abstractfactory pattern. > >It's quite overblown outside of multi-tier applications. > > > >>i would argue that can be a strength of multiple methods. It forces a >>private vs public methods implementation, and stops a later developer >>from blowing a hole in the application by developing >>MyImplemention->admin_function() only to find out that without his/her >>knowledge, it's become a function available to anyone with a web browser. >> >> > >I think only a very naive implementation of the dispatch approach >would allow such. E.g., all the sample code in this thread checked the >allowedness of a method. > yeah, good point. > > From mjs at beebo.org Tue Nov 5 07:09:22 2002 From: mjs at beebo.org (Michael Stillwell) Date: Wed Aug 4 00:02:45 2004 Subject: Paradigms for CGI application development? Message-ID: Good CGI discussion this week! I've been thinking recently about some of the more crapful aspects of CGI application development. In particular, what techniques to people use to get around the fact that CGI applications don't get the (surprisingly helpful) implicit preconditions and automatic stack and scope maintenance bits and pieces that regular applications get for free (simply by ordering and nesting statements)? For example, in a regular application, to get the user to confirm the transfer of some amount of money from one account to another is a matter of a few lines of code like: if (confirm(sprintf("Really transfer %d dollars from %s to %s?", $n, $a1, $a2))) { # DO TRANSFER message("Transfer successful"); } else { # ABORT TRANSFER message("Transfer aborted"); } To get the equivalent effect in a CGI application (where the "confirm" screen appears on a separate page) you need to do an amazing number of things yourself: 1. Because Perl doesn't make it very convenient to jump (or transfer control) to the *middle* of a function (actually, I'm not sure that this is even possible), you need to break your functions in two whenever you seek user input. So in the example above, the code following the call to confirm() must appear in a separate function. Another shitty consequence of this is that you must supply the "return address" to confirm() yourself: sub transfer_part1 { # ... confirm("Really transfer?", "transfer_part2"); } sub transfer_part2 { my ($result) = @_; if ($result) { # DO TRANSFER } else { # ABORT TRANSFER } } 2. You need to save and restore state information, so that when you return from the confirm "call" (in transfer_part2()) you know what $n, $a1 and $a2 were, as well as what the account number was, etc. (And, you can't use any sort of conventional stack for this because you have almost no control over the route the user takes through your program. For example, you can't even guarantee that confirm() will return before something happens elsewhere in your program, because the user backed up a few pages and hit submit.) 3. You need to confirm, in transfer_part2() that the user really is who they say they are. How do people get around these problems? Why is the code for web app UIs very different to that of desktop app UIs? I suppose some of these problems could be solved if the web server kept the running program in memory across requests (instead of starting a new instance each time), but I don't know of any system that does this. Are there any? (And I haven't thought about it much, but I suspect this approach would also be horribly complicated too, albeit in different ways.) --M. * * * http://beebo.org From david_dick at iprimus.com.au Wed Nov 6 00:48:23 2002 From: david_dick at iprimus.com.au (David Dick) Date: Wed Aug 4 00:02:45 2004 Subject: Paradigms for CGI application development? In-Reply-To: References: Message-ID: <3DC8BB37.8020703@iprimus.com.au> Michael Stillwell wrote: > Good CGI discussion this week! > > I've been thinking recently about some of the more crapful aspects of > CGI application development. In particular, what techniques to people > use to get around the fact that CGI applications don't get the > (surprisingly helpful) implicit preconditions and automatic stack and > scope maintenance bits and pieces that regular applications get for > free (simply by ordering and nesting statements)? The way i've always thought of it is that CGI/mod_perl development is _always_ going to be significantly slower than GUI apps to develop, because you have to build everything in CGI from scratch, namely the truely horrific possiblities of stateless connections (attaching last_updated & last_updated_by fields to _every_ screen of updatable data at least). However, the longer development cycle is far outweighed by the fact that a bugfix/feature add to an application rolled out to 100's+ users can be re-rolled out in a matter of milli-seconds with a CGI app. (It also means that you are developing with the maintenance cycle in mind, so it's more important than usual to comment and code cleanly. :) Another thing is that lots of the stuff you mention can be significantly reduced by getting a good application framework. I can't say I can recommend one (anyone?), cos I tend to carry around one that i wrote myself, but once you get comfortable with a good framework, a lot of these hassles should go away. > > > For example, in a regular application, to get the user to confirm the > transfer of some amount of money from one account to another is a > matter of a few lines of code like: > > if (confirm(sprintf("Really transfer %d dollars from %s to %s?", $n, > $a1, $a2))) { > # DO TRANSFER > message("Transfer successful"); > } > > else { > # ABORT TRANSFER > message("Transfer aborted"); > } > > To get the equivalent effect in a CGI application (where the "confirm" > screen appears on a separate page) you need to do an amazing number of > things yourself: > > 1. Because Perl doesn't make it very convenient to jump (or transfer > control) to the *middle* of a function (actually, I'm not sure that > this is even possible), you need to break your functions in two > whenever you seek user input. So in the example above, the code > following the call to confirm() must appear in a separate function. > Another shitty consequence of this is that you must supply the "return > address" to confirm() yourself: > > sub transfer_part1 { > # ... > confirm("Really transfer?", "transfer_part2"); > } > > sub transfer_part2 { > my ($result) = @_; > > if ($result) { > # DO TRANSFER > } > > else { > # ABORT TRANSFER > } > } > > 2. You need to save and restore state information, so that when you > return from the confirm "call" (in transfer_part2()) you know what $n, > $a1 and $a2 were, as well as what the account number was, etc. (And, > you can't use any sort of conventional stack for this because you have > almost no control over the route the user takes through your program. > For example, you can't even guarantee that confirm() will return > before something happens elsewhere in your program, because the user > backed up a few pages and hit submit.) > > 3. You need to confirm, in transfer_part2() that the user really is > who they say they are. > > How do people get around these problems? Why is the code for web app > UIs very different to that of desktop app UIs? I suppose some of > these problems could be solved if the web server kept the running > program in memory across requests (instead of starting a new instance > each time), but I don't know of any system that does this. Are there > any? (And I haven't thought about it much, but I suspect this > approach would also be horribly complicated too, albeit in different > ways.) > > > > > > --M. > > * * * > http://beebo.org > > From david_dick at iprimus.com.au Wed Nov 6 01:19:27 2002 From: david_dick at iprimus.com.au (David Dick) Date: Wed Aug 4 00:02:45 2004 Subject: XSS,CGI && Template Toolkit In-Reply-To: References: <3DC8BB37.8020703@iprimus.com.au> Message-ID: <3DC8C27F.4010301@iprimus.com.au> Got a bit of a problem with Cross Site Scripting. The way I've been writing web apps is by using $cgi->param to suck in values from the user and using the Template Toolkit to generate the html. However, CGI.pm seems to assume that you'll use the CGI.pm routines to output html, so the param method unencodes everything it can, while the CGI.pm output commands encodes them. Translated..... will be translated by $cgi->param into