From sigzero at gmail.com  Tue Jan  1 15:38:23 2008
From: sigzero at gmail.com (Robert Hicks)
Date: Tue Jan  1 15:39:18 2008
Subject: [cgiapp] Nothing fancy but IE chokes?
Message-ID: <fle8c3$otb$1@ger.gmane.org>

I have a simple site:

www.skylinebaptist.us

IE for some reason cannot navigate to:

http://www.skylinebaptist.us/index.cgi?rm=ministries

Firefox has no problem at all. Any idea why IE barfs (besides IE is crap)?

Robert

From Kezmega at sbcglobal.net  Tue Jan  1 16:02:57 2008
From: Kezmega at sbcglobal.net (Kevin)
Date: Tue Jan  1 16:01:37 2008
Subject: [cgiapp] Nothing fancy but IE chokes?
References: <fle8c3$otb$1@ger.gmane.org>
Message-ID: <000b01c84cb9$afc3bac0$6401a8c0@kezmegahome>

Robert,

I believe the page is not being rendered because of a missing bracket on the 
opening tag for the title.

Kevin

----- Original Message ----- 
From: "Robert Hicks" <sigzero@gmail.com>
To: <cgiapp@lists.erlbaum.net>
Sent: Tuesday, January 01, 2008 2:38 PM
Subject: [cgiapp] Nothing fancy but IE chokes?


>I have a simple site:
>
> www.skylinebaptist.us
>
> IE for some reason cannot navigate to:
>
> http://www.skylinebaptist.us/index.cgi?rm=ministries
>
> Firefox has no problem at all. Any idea why IE barfs (besides IE is crap)?
>
> Robert
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
> 

From karen.cravens at gmail.com  Tue Jan  1 16:06:05 2008
From: karen.cravens at gmail.com (Karen)
Date: Tue Jan  1 16:06:08 2008
Subject: [cgiapp] Nothing fancy but IE chokes?
In-Reply-To: <000b01c84cb9$afc3bac0$6401a8c0@kezmegahome>
References: <fle8c3$otb$1@ger.gmane.org>
	<000b01c84cb9$afc3bac0$6401a8c0@kezmegahome>
Message-ID: <7cc7c1ce0801011306k6dc75a3brd51b1d79c1fdc6c7@mail.gmail.com>

On 1/1/08, Kevin <Kezmega@sbcglobal.net> wrote:
> Robert,
>
> I believe the page is not being rendered because of a missing bracket on the
> opening tag for the title.

Good catch.  Robert, you might want to try validating pages, like so:

http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.skylinebaptist.us%2Findex.cgi%3Frm%3Dministries

That often catches things that don't show up otherwise.
From sigzero at gmail.com  Tue Jan  1 16:09:38 2008
From: sigzero at gmail.com (Robert Hicks)
Date: Tue Jan  1 16:10:50 2008
Subject: [cgiapp] Re: Nothing fancy but IE chokes?
In-Reply-To: <000b01c84cb9$afc3bac0$6401a8c0@kezmegahome>
References: <fle8c3$otb$1@ger.gmane.org>
	<000b01c84cb9$afc3bac0$6401a8c0@kezmegahome>
Message-ID: <flea6m$t74$1@ger.gmane.org>

You are right *but* the code for that comes from:

<title>[% webpage_title %]</title>

That was wierd...I simple re-wrote it character for character and it now 
prints out the right HTML.  Hmmm

Kevin wrote:
> Robert,
> 
> I believe the page is not being rendered because of a missing bracket on 
> the opening tag for the title.
> 
> Kevin
> 
> ----- Original Message ----- From: "Robert Hicks" <sigzero@gmail.com>

From sigzero at gmail.com  Tue Jan  1 16:59:45 2008
From: sigzero at gmail.com (Robert Hicks)
Date: Tue Jan  1 17:00:15 2008
Subject: [cgiapp] Re: Nothing fancy but IE chokes?
In-Reply-To: <7cc7c1ce0801011306k6dc75a3brd51b1d79c1fdc6c7@mail.gmail.com>
References: <fle8c3$otb$1@ger.gmane.org>	<000b01c84cb9$afc3bac0$6401a8c0@kezmegahome>
	<7cc7c1ce0801011306k6dc75a3brd51b1d79c1fdc6c7@mail.gmail.com>
Message-ID: <fled4k$5f9$1@ger.gmane.org>

Karen wrote:
> On 1/1/08, Kevin <Kezmega@sbcglobal.net> wrote:
>> Robert,
>>
>> I believe the page is not being rendered because of a missing bracket on the
>> opening tag for the title.
> 
> Good catch.  Robert, you might want to try validating pages, like so:
> 
> http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.skylinebaptist.us%2Findex.cgi%3Frm%3Dministries
> 
> That often catches things that don't show up otherwise.
> 

Thanks! Yes I should be using that.  : )

Robert

From mpeters at plusthree.com  Tue Jan  1 17:49:18 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Tue Jan  1 17:50:45 2008
Subject: [cgiapp] Re: Nothing fancy but IE chokes?
In-Reply-To: <flea6m$t74$1@ger.gmane.org>
References: <fle8c3$otb$1@ger.gmane.org>	<000b01c84cb9$afc3bac0$6401a8c0@kezmegahome>
	<flea6m$t74$1@ger.gmane.org>
Message-ID: <477AC36E.9090806@plusthree.com>

Robert Hicks wrote:
> You are right *but* the code for that comes from:
> 
> <title>[% webpage_title %]</title>

This probably isn't your problem, but all input that goes in your templates
should be HTML escaped unless you know it has been earlier. TT makes this very easy:

  <title>[% wepage_title | html %]</title>

Not only will this allow your variables to contain things like "&" and "<"
without problems, but it will also protect you against XSS attacks.

-- 
Michael Peters
Developer
Plus Three, LP

From sigzero at gmail.com  Tue Jan  1 21:11:20 2008
From: sigzero at gmail.com (Robert Hicks)
Date: Tue Jan  1 21:11:42 2008
Subject: [cgiapp] Re: Nothing fancy but IE chokes?
In-Reply-To: <477AC36E.9090806@plusthree.com>
References: <fle8c3$otb$1@ger.gmane.org>	<000b01c84cb9$afc3bac0$6401a8c0@kezmegahome>	<flea6m$t74$1@ger.gmane.org>
	<477AC36E.9090806@plusthree.com>
Message-ID: <flersc$9io$1@ger.gmane.org>

Michael Peters wrote:
> Robert Hicks wrote:
>> You are right *but* the code for that comes from:
>>
>> <title>[% webpage_title %]</title>
> 
> This probably isn't your problem, but all input that goes in your templates
> should be HTML escaped unless you know it has been earlier. TT makes this very easy:
> 
>   <title>[% wepage_title | html %]</title>
> 
> Not only will this allow your variables to contain things like "&" and "<"
> without problems, but it will also protect you against XSS attacks.
> 

Thanks for the tip!

Robert

From adam at spatialsystems.org  Tue Jan  1 21:59:58 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Tue Jan  1 22:00:00 2008
Subject: [cgiapp] Adding Footer to Output
Message-ID: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>

I'm adding a footer and I'm using HTML::Template.  I'll be including a generic footer using TMPL_INCLUDE and pass the current year to the included footer for the copyright date.
 
What's the best way to send this info without having to explicitly sending a TMPL_VAR for the year each time?  I'd like this to be automatic.
 
Thanks,
Adam
From mpeters at plusthree.com  Wed Jan  2 09:22:31 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Wed Jan  2 09:23:46 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
Message-ID: <477B9E27.8020404@plusthree.com>

adam@spatialsystems.org wrote:
> I'm adding a footer and I'm using HTML::Template.  I'll be including a generic 
> footer using TMPL_INCLUDE and pass the current year to the included footer for
the
> copyright date.

Just saying something is copyrighted doesn't make it so :)

> What's the best way to send this info without having to explicitly sending a 
> TMPL_VAR for the year each time?  I'd like this to be automatic.

There's no way to do this "automatically" using H::T. You can't run code in H::T
templates, just put markup around variables that you explicitly pass in.

-- 
Michael Peters
Developer
Plus Three, LP

From perl at rhesa.com  Wed Jan  2 09:52:14 2008
From: perl at rhesa.com (Rhesa Rozendaal)
Date: Wed Jan  2 09:52:22 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
Message-ID: <477BA51E.3080505@rhesa.com>

adam@spatialsystems.org wrote:
> I'm adding a footer and I'm using HTML::Template.  I'll be including a generic footer using TMPL_INCLUDE and pass the current year to the included footer for the copyright date.
>  
> What's the best way to send this info without having to explicitly sending a TMPL_VAR for the year each time?  I'd like this to be automatic.

You can do this with a callback to 'load_tmpl':

     sub my_load_tmpl_callback {
         my ($self, $ht_params, $tmpl_params, $tmpl_file) = @_;
	
         $tmpl_params->{YEAR} ||= current_year();
     }

Setting up the callback can be done at several points, but I'd suggest doing 
it inside setup() for simplicity:

     sub setup {
         my $self = shift;

         # other setup stuff
         # ...

         # set default params
         $self->add_callback('load_tmpl',\&my_load_tmpl_callback);
    }

Refer to the CGI::Application docs for more information on callbacks.

HTH,

Rhesa
From karen.cravens at gmail.com  Wed Jan  2 10:27:38 2008
From: karen.cravens at gmail.com (Karen)
Date: Wed Jan  2 10:27:41 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <477B9E27.8020404@plusthree.com>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
	<477B9E27.8020404@plusthree.com>
Message-ID: <7cc7c1ce0801020727t68e94072wc65f0d0ae66ce9c9@mail.gmail.com>

On 1/2/08, Michael Peters <mpeters@plusthree.com> wrote:

> Just saying something is copyrighted doesn't make it so :)

Continuously moving the copyright date is a pet peeve of mine, too.

Things are copyrighted when they're first committed to fixed form. You
don't get to keep moving the copyright date unless you make
substantial changes, and even then the original version still keeps
the older copyright date.

If you want permanent copyright, you have to do it the honest way,
like Disney, and get Congress to keep extending the term indefinitely.
From mpeters at plusthree.com  Wed Jan  2 10:29:07 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Wed Jan  2 10:30:21 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <7cc7c1ce0801020727t68e94072wc65f0d0ae66ce9c9@mail.gmail.com>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>	<477B9E27.8020404@plusthree.com>
	<7cc7c1ce0801020727t68e94072wc65f0d0ae66ce9c9@mail.gmail.com>
Message-ID: <477BADC3.60305@plusthree.com>

Karen wrote:

> If you want permanent copyright, you have to do it the honest way,
> like Disney, and get Congress to keep extending the term indefinitely.

I have to say that this made my day :) Although I'd probably =~ s/get/bribe/

-- 
Michael Peters
Developer
Plus Three, LP

From karen.cravens at gmail.com  Wed Jan  2 10:51:52 2008
From: karen.cravens at gmail.com (Karen)
Date: Wed Jan  2 10:51:55 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <477BADC3.60305@plusthree.com>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
	<477B9E27.8020404@plusthree.com>
	<7cc7c1ce0801020727t68e94072wc65f0d0ae66ce9c9@mail.gmail.com>
	<477BADC3.60305@plusthree.com>
Message-ID: <7cc7c1ce0801020751t2d9b9ec3k292876e958cb0345@mail.gmail.com>

On 1/2/08, Michael Peters <mpeters@plusthree.com> wrote:
> I have to say that this made my day :) Although I'd probably =~ s/get/bribe/

Heh. I opted to keep the level at "snark" and not "actionable."

Soapboxing aside, I suspect that the usual reason for updates is
either a simple misunderstanding of the notice's meaning (just because
something was copyrighted last year doesn't mean it's expired this
year) or technical issues (we don't know exactly when the particular
bit of content was created, so we give the whole site the date of the
newest content).

I don't like the latter, as it dilutes the notices to where I would
expect a judge to deny you statutory damages, i.e. same as when you
don't have a properly-formatted notice at all. I'd rather be up-front
about it and put a generic notice without a year. It doesn't qualify
for statutory damages either, but they seem unlikely anyway.

Were it a site statutory damages were a realistic possibility, I'd
care enough to track the correct date for every bit of content, and
then I'd be explicitly setting a TMPL_VAR.
From geconomou at gmail.com  Wed Jan  2 11:06:46 2008
From: geconomou at gmail.com (Giannis Economou)
Date: Wed Jan  2 11:07:01 2008
Subject: [cgiapp] 
	Bug-Problem with CGI.pm, fcgid, CGI::Application and utf-8?
Message-ID: <477BB696.8060304@gmail.com>

Hello,

I'm writing to report a nasty situation/bug I'm facing. It is quite
strange to me, I can not find out which component might be fully
responsible (maybe just CGI.pm or the combination of C::A and CGI.pm)
and I gave some hours to isolate the situation as much as possible and
reproduce it. Maybe someone is also interest or can help.
I explain and afterwards I send you some sample code you can try.

I have some applications written, now in production installation, using
C::A. They are different apps, using many CGI::App modules and C::A
Plugins and they show output (html) in utf-8. Among other they also use
TT2, but this is also irrelevant to the problem.
All started when I accidentally found out that when cookies are disabled
(in firefox or ie) then web pages do not display the utf-8 correctly,
but when cookies are enabled, everything is displayed correctly!


I've managed to isolate the problem (as you can guess I started being
suspicious with many modules in the way before stripping everything in a
new test case).
It happens only with:
- C::A applications (simple cgi script are not having the problem)
- running on my server (Linux, Apache/2.0.52, Perl v5.8.5), I haven't
tried other servers, but I guess it will be also have the problem
- only when run under fcgid acceleration (plain cgi execution has
consistent behavior), I also tried the latest fcgid module on my Apache
no luck
- only when using CGI.pm (with CGI::Simple this problem is not
happening, utf-8 is always displayed right) - my CGI.pm is version 3.31.

It is frustrating, mostly because I was really happy with fcgid as
acceleration of my apps until today. Now I had to switch to plain cgi again.



Here is a sample source that demonstrates and reproduce the problem,
using the bare/minimal modules to reproduce it:

############### (instance.fcgi) ###############

#!/usr/bin/perl
use CGI::Fast;
use WebApp;

while (new CGI::Fast) {
my $self = WebApp->new();
$self->run();
}


############### (WebApp.pm) ###############

package WebApp;
use base 'CGI::Application';

sub setup {
my $self = shift;
$self->start_mode('test');
$self->mode_param('rm');
$self->run_modes(
'test' => 'show_test',
);
$self->header_add( -charset => 'utf-8' );
}

sub show_test {
my $self = shift;
my $cookie = $self->query->cookie(-name=>'test', -value=>'foo');
$self->header_add(-cookie=>$cookie); #set the cookie

return "Hello ... ????????!"; #this is 'Good morning' in Greek, file is
saved as utf-8
}

1;


Now:
- when you run the instance.fcgi as fcgid script, cookie is set and in
browser you get garbage in the Greek text (encoding is correctly set in
browser).
- when you run the instance.fcgi as plain cgi script, everything is fine
- when you comment the cookie setting line in WebApp.pm, everything is
working fine, regardless of fcgid or plain cgi.
- when you use CGI::Simple instead of CGI.pm (for example use a
CGI::Simple object instead of $self->query which is a CGI.pm in the
example above to create the cookie), everything is working fine (fcgi /
plain cgi, set cookie / do not set cookie, everything is fine).

Here is the output of CGI::Application, as sent in browser, but as
unicode codes:
Correct:
Hello ... \xce\x9a\xce\xb1\xce\xbb\xce\xb7\xce\xbc\xce\xad\xcf\x81\xce\xb1!

Erroneous:
Hello ...
\xc3\x8e\xc2\x9a\xc3\x8e\xc2\xb1\xc3\x8e\xc2\xbb\xc3\x8e\xc2\xb7\xc3\x8e\xc2\xbc\xc3\x8e\xc2\xad\xc3\x8f\xc2\x81\xc3\x8e\xc2\xb1!


Best regards,
Giannis Economou




From adam at spatialsystems.org  Wed Jan  2 11:57:35 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Wed Jan  2 11:57:37 2008
Subject: [cgiapp] Adding Footer to Output
Message-ID: <20080102095735.292eb6c930850de810cf35869bff7bc4.cf570f66a7.wbe@email.secureserver.net>

I know it really doesn't matter.  This is more of an exercise of leaning CGI::Application, plus I know it will come in useful.

Thanks for everyones help, I'll try the callback.


--------------------------------------------------------------------
On 1/2/08, Karen <karen.cravens@gmail.com> wrote:
>Soapboxing aside, I suspect that the usual reason for updates is
>either a simple misunderstanding of the notice's meaning (just because
>something was copyrighted last year doesn't mean it's expired this
>year) or technical issues (we don't know exactly when the particular
>bit of content was created, so we give the whole site the date of the
>newest content).


From ron at savage.net.au  Wed Jan  2 17:21:18 2008
From: ron at savage.net.au (Ron Savage)
Date: Wed Jan  2 17:20:50 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <7cc7c1ce0801020727t68e94072wc65f0d0ae66ce9c9@mail.gmail.com>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
	<477B9E27.8020404@plusthree.com>
	<7cc7c1ce0801020727t68e94072wc65f0d0ae66ce9c9@mail.gmail.com>
Message-ID: <1199312478.4553.5.camel@zoe.savage.net.au>

On Wed, 2008-01-02 at 09:27 -0600, Karen wrote:

Hi Karen

> If you want permanent copyright, you have to do it the honest way,
> like Disney, and get Congress to keep extending the term indefinitely.

Ah, yes. The American Way.

Note also that the 3-character symbol (C) is not a copyright symbol in
some countries, e.g. Australia.

<even_more_off_topic>
This raises the intriguing question of why IBM refused to put the
copyright symbol in the original PC's character set...
</even_more_off_topic>

-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ron at savage.net.au  Wed Jan  2 18:21:28 2008
From: ron at savage.net.au (Ron Savage)
Date: Wed Jan  2 18:20:58 2008
Subject: [cgiapp]  Bug-Problem with CGI.pm, fcgid, CGI::Application and
	utf-8?
In-Reply-To: <477BB696.8060304@gmail.com>
References: <477BB696.8060304@gmail.com>
Message-ID: <1199316088.4553.15.camel@zoe.savage.net.au>

On Wed, 2008-01-02 at 18:06 +0200, Giannis Economou wrote:

Hi Giannis

Debian and Apache/2.2.6 (Unix) mod_fastcgi/2.4.6 mod_perl/2.0.3
Perl/v5.8.8 here.

> Now:
> - when you run the instance.fcgi as fcgid script, cookie is set and in
> browser you get garbage in the Greek text (encoding is correctly set in
> browser).

Same here.

> - when you run the instance.fcgi as plain cgi script, everything is fine

Same here.

> - when you comment the cookie setting line in WebApp.pm, everything is
> working fine, regardless of fcgid or plain cgi.

Same here.

> - when you use CGI::Simple instead of CGI.pm (for example use a
> CGI::Simple object instead of $self->query which is a CGI.pm in the
> example above to create the cookie), everything is working fine (fcgi /
> plain cgi, set cookie / do not set cookie, everything is fine).

Same here.

> Here is the output of CGI::Application, as sent in browser, but as
> unicode codes:
> Correct:
> Hello ... \xce\x9a\xce\xb1\xce\xbb\xce\xb7\xce\xbc\xce\xad\xcf\x81\xce\xb1!
> 
> Erroneous:
> Hello ...
> \xc3\x8e\xc2\x9a\xc3\x8e\xc2\xb1\xc3\x8e\xc2\xbb\xc3\x8e\xc2\xb7\xc3\x8e\xc2\xbc\xc3\x8e\xc2\xad\xc3\x8f\xc2\x81\xc3\x8e\xc2\xb1!

I'd try double-encoding the correct text and/or double-decoding the
incorrect text. Perhaps that will tell you something.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From karen.cravens at gmail.com  Thu Jan  3 00:18:38 2008
From: karen.cravens at gmail.com (Karen)
Date: Thu Jan  3 00:18:43 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <1199312478.4553.5.camel@zoe.savage.net.au>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
	<477B9E27.8020404@plusthree.com>
	<7cc7c1ce0801020727t68e94072wc65f0d0ae66ce9c9@mail.gmail.com>
	<1199312478.4553.5.camel@zoe.savage.net.au>
Message-ID: <7cc7c1ce0801022118x2a289ef8jd1c83204d19ebd30@mail.gmail.com>

On 1/2/08, Ron Savage <ron@savage.net.au> wrote:

> Note also that the 3-character symbol (C) is not a copyright symbol in
> some countries, e.g. Australia.

The US, as well. "Copr." is the shortest legal way to represent it
here if you can't do a proper circled-C.
From dan.horne at redbone.co.nz  Thu Jan  3 04:44:17 2008
From: dan.horne at redbone.co.nz (Dan Horne)
Date: Thu Jan  3 04:43:04 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <477B9E27.8020404@plusthree.com>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
	<477B9E27.8020404@plusthree.com>
Message-ID: <477CAE71.7070303@redbone.co.nz>

Michael Peters wrote:
> Just saying something is copyrighted doesn't make it so :)
>   
Er, assuming you're that actual author, why not?

From mpeters at plusthree.com  Thu Jan  3 08:10:01 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Thu Jan  3 09:49:59 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <477CAE71.7070303@redbone.co.nz>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>	<477B9E27.8020404@plusthree.com>
	<477CAE71.7070303@redbone.co.nz>
Message-ID: <477CDEA9.7050904@plusthree.com>

Dan Horne wrote:
> Michael Peters wrote:
>> Just saying something is copyrighted doesn't make it so :)
>>   
> Er, assuming you're that actual author, why not?

I'm not a lawyer (would I be hanging out here if I was :) and it has been some
years since my last copyright law class at the university (so please correct me
if I'm wrong) but here goes...

Actual copyright registration means something different then the automatic
copyright rights provided by the Berne Convention (which basically took effect
in 1989 in the US). Putting a "(C) 2008" on something is supposed to mean that
you've officially registered the copyright with the appropriate government
office. And then the year is the year the work was completed. If it's something
that you wrote in 2007 it's misleading (and probably "wrong" in some way) to say
"(C) 2008". In fact, lying about the copyright date on something you wrote could
probably lose you some points with a judge if you actually have to go to court.

Since some copyright protections are automatic the reason you register is to
make it easier to enforce monetary damages. Putting "(C) 2008" one something
does not give you any extra legal protection or enforcement possibilities, so
why do it?

-- 
Michael Peters
Developer
Plus Three, LP

From karen.cravens at gmail.com  Thu Jan  3 19:17:51 2008
From: karen.cravens at gmail.com (Karen)
Date: Thu Jan  3 19:17:53 2008
Subject: [cgiapp] Adding Footer to Output
In-Reply-To: <477CAE71.7070303@redbone.co.nz>
References: <20080101195958.292eb6c930850de810cf35869bff7bc4.bab4342a59.wbe@email.secureserver.net>
	<477B9E27.8020404@plusthree.com> <477CAE71.7070303@redbone.co.nz>
Message-ID: <7cc7c1ce0801031617w50038c6bg41114751db09dbeb@mail.gmail.com>

On 1/3/08, Dan Horne <dan.horne@redbone.co.nz> wrote:
> Michael Peters wrote:
> > Just saying something is copyrighted doesn't make it so :)
> >
> Er, assuming you're that actual author, why not?

(Under US law, and I think all the Berne signatories, as I understand
them. YMMV.)

Something is copyrighted the moment it's put into fixed form. The
copyright notice only entitles you to seek statutory (I think)
damages, presumeably on the principle that the infringer *really*
should have known better. But the notice has to be in a specific
format: "Copyright YYYY Copyright Holder's Name," where you can
abbreviate it to "Copr." or use the (fully) circled-C symbol.

In 2008, you don't update all your 2007 copyright notices... the 2007
ones are good indefinitely.  (Technically, there's a limit. The US
Constitution mandates one. But Congress keeps bumping the limit
further out, which somehow doesn't count as being unlimited. But in
Internet time, it's forever for all practical purposes.) If you keep
updating your copyright notices, I imagine there are judges who would
throw them out for purposes of damages.

If you don't intend to seek damages, of course, you don't have to
worry about getting the exact legality right - you're just trying to
remind people that the copyright is there, since there are a lot of
people who still assume that if it doesn't say otherwise, it's public
domain. For that, you'd probably be better served with an undated
copyright notice, and then a "last updated" with that year in it,
though.

(I am not a lawyer, I just have worked in several fields that involve
copyright and accordingly have read a lot of lawyers' interpretations
for laymen.)
From stefan.petrea at gmail.com  Sat Jan  5 14:19:36 2008
From: stefan.petrea at gmail.com (Stefan Petrea)
Date: Sun Jan  6 00:18:51 2008
Subject: [cgiapp] headers problem
Message-ID: <200801052119.36944.stefan.petrea@gmail.com>

Hi,

I'm very new to CGI::Application
I'm using this example here http://www.redantigua.com/cgi-application1.html for
learning how to use CGI::Application.
I get 500 every time I run helloworld.cgi-app.pl 
What can I do about this ?
It just seems that the pl is not sending any headers.
How can I solve this problem ?
thank you
From adam at spatialsystems.org  Sun Jan  6 01:24:19 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Sun Jan  6 01:24:22 2008
Subject: [cgiapp] headers problem
Message-ID: <20080105232419.292eb6c930850de810cf35869bff7bc4.f2423a4d45.wbe@email.secureserver.net>

I'm very new at CGI::Application too, but I'd say make sure you have CGI::Application and HTML::Template installed.  Try using "CGI::Carp qw( fatalsToBrowser )" and try invoking the application from your shell and see what happens.  Maybe you're getting some kind of error.



-------- Original Message --------
Subject: [cgiapp] headers problem
From: Stefan Petrea <stefan.petrea@gmail.com>
Date: Sat, January 05, 2008 1:19 pm
To: cgiapp@lists.erlbaum.net

Hi,

I'm very new to CGI::Application
I'm using this example here http://www.redantigua.com/cgi-application1.html for
learning how to use CGI::Application.
I get 500 every time I run helloworld.cgi-app.pl 
What can I do about this ?
It just seems that the pl is not sending any headers.
How can I solve this problem ?
thank you

##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################



From ron at savage.net.au  Sun Jan  6 01:26:48 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Jan  6 01:26:16 2008
Subject: *****SPAM***** [cgiapp] headers problem
In-Reply-To: <200801052119.36944.stefan.petrea@gmail.com>
References: <200801052119.36944.stefan.petrea@gmail.com>
Message-ID: <1199600808.4517.9.camel@zoe.savage.net.au>

On Sat, 2008-01-05 at 21:19 +0200, Stefan Petrea wrote:

Hi Stefan

> I'm very new to CGI::Application

Welcome to the club!

> I'm using this example here http://www.redantigua.com/cgi-application1.html for
> learning how to use CGI::Application.
> I get 500 every time I run helloworld.cgi-app.pl 
> What can I do about this ?
> It just seems that the pl is not sending any headers.
> How can I solve this problem ?

Things to check:

1) Is the template in the same directory as the CGI script? It should
be, because of this line (IMHO):
   $self->tmpl_path('./');
in the *.pm file

2) Are the permissions correct on /all/ 3 files?
 - CGI script
 - Template
 - *.pm
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From stefan.petrea at gmail.com  Sat Jan  5 15:30:59 2008
From: stefan.petrea at gmail.com (Stefan Petrea)
Date: Sun Jan  6 01:30:14 2008
Subject: [cgiapp] headers problem
In-Reply-To: <20080105232419.292eb6c930850de810cf35869bff7bc4.f2423a4d45.wbe@email.secureserver.net>
References: <20080105232419.292eb6c930850de810cf35869bff7bc4.f2423a4d45.wbe@email.secureserver.net>
Message-ID: <200801052230.59584.stefan.petrea@gmail.com>

On Sunday 06 January 2008 08:24, adam@spatialsystems.org wrote:
Hi,
I've just tried "use CGI::Carp qw( fatalsToBrowser )" and nothing changed
in the sense that from console it still works OK but from the browser I still get 500
> I'm very new at CGI::Application too, but I'd say make sure you have CGI::Application and HTML::Template installed.  Try using "CGI::Carp qw( fatalsToBrowser )" and try invoking the application from your shell and see what happens.  Maybe you're getting some kind of error.
> 
> 
> 
> -------- Original Message --------
> Subject: [cgiapp] headers problem
> From: Stefan Petrea <stefan.petrea@gmail.com>
> Date: Sat, January 05, 2008 1:19 pm
> To: cgiapp@lists.erlbaum.net
> 
> Hi,
> 
> I'm very new to CGI::Application
> I'm using this example here http://www.redantigua.com/cgi-application1.html for
> learning how to use CGI::Application.
> I get 500 every time I run helloworld.cgi-app.pl 
> What can I do about this ?
> It just seems that the pl is not sending any headers.
> How can I solve this problem ?
> thank you
> 
> ##### CGI::Application community mailing list ################
> ## ##
> ## To unsubscribe, or change your message delivery options, ##
> ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
> ## ##
> ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
> ## Wiki: http://cgiapp.erlbaum.net/ ##
> ## ##
> ################################################################
> 
> 
> 
> 
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
> 
> 
From stefan.petrea at gmail.com  Sat Jan  5 16:11:21 2008
From: stefan.petrea at gmail.com (Stefan Petrea)
Date: Sun Jan  6 02:10:33 2008
Subject: *****SPAM***** [cgiapp] headers problem
In-Reply-To: <1199600808.4517.9.camel@zoe.savage.net.au>
References: <200801052119.36944.stefan.petrea@gmail.com>
	<1199600808.4517.9.camel@zoe.savage.net.au>
Message-ID: <200801052311.21135.stefan.petrea@gmail.com>

On Sunday 06 January 2008 08:26, Ron Savage wrote:
ok I just checked 1 and 2 you wrote and they are ok.
I've modified httpd.conf so that it has Option +ExecCGI on the directory where the code is located.
Now I get a long wait after wich I still get 500.
> On Sat, 2008-01-05 at 21:19 +0200, Stefan Petrea wrote:
> 
> Hi Stefan
> 
> > I'm very new to CGI::Application
> 
> Welcome to the club!
> 
> > I'm using this example here http://www.redantigua.com/cgi-application1.html for
> > learning how to use CGI::Application.
> > I get 500 every time I run helloworld.cgi-app.pl 
> > What can I do about this ?
> > It just seems that the pl is not sending any headers.
> > How can I solve this problem ?
> 
> Things to check:
> 
> 1) Is the template in the same directory as the CGI script? It should
> be, because of this line (IMHO):
>    $self->tmpl_path('./');
> in the *.pm file
> 
> 2) Are the permissions correct on /all/ 3 files?
>  - CGI script
>  - Template
>  - *.pm
From mpeters at plusthree.com  Sun Jan  6 19:04:22 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Sun Jan  6 19:05:41 2008
Subject: *****SPAM***** [cgiapp] headers problem
In-Reply-To: <200801052311.21135.stefan.petrea@gmail.com>
References: <200801052119.36944.stefan.petrea@gmail.com>	<1199600808.4517.9.camel@zoe.savage.net.au>
	<200801052311.21135.stefan.petrea@gmail.com>
Message-ID: <47816C86.8050101@plusthree.com>

Stefan Petrea wrote:

> Now I get a long wait after wich I still get 500.

Look at your server's error logs. Until you do nothing we tell you will be more
than just a guess. The server's error log is one of your best friends for web
development.

-- 
Michael Peters
Developer
Plus Three, LP

From adam at spatialsystems.org  Mon Jan  7 17:39:01 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Mon Jan  7 17:39:03 2008
Subject: [cgiapp] Saving Data From Authentication Phase
Message-ID: <20080107153901.292eb6c930850de810cf35869bff7bc4.5e55c1a315.wbe@email.secureserver.net>

I'm using CGI::Application::Plugin::Session and CGI::Application::Plugin::Authentication.  With CGI::Application::Plugin::Authentication I'm using the Generic driver.

I have an authentication object in my anonymous subroutine ref that I use for authentication with the Generic driver.  The authentication object returns 0 or 1 if the username/password is valid or not.  And I can also ask for the users info after the user is logged in and it returns a hashref.

How can I save this hashref of user info and keep it in my Session for all requests where the user is logged in?

Here is some of my code:

sub setup {

	#  setup authentication
	$self->authen->config(
		DRIVER	=> [ 'Generic', \&my_login ],
		STORE		=> 'Session',
		LOGIN_RUNMODE	=> 'login',
		POST_LOGIN_RUNMODE => 'main',
		LOGOUT_RUNMODE	=> 'login',
	);

}

sub my_login {

	my ($username, $password) = @_;

	#  connect to auth network
	my $ad_auth = MyCompany::ActiveDirectory->new('WINDOWS');

	return 0 if not $ad_auth->login( $username, $password );

	#  how do I store this info in the hash ref so I always have it???
	$users_hash_ref = $ad_auth->getUserInfo;

	retrun 1;

}


Thanks,
Adam

From adam at spatialsystems.org  Mon Jan  7 21:47:28 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Mon Jan  7 21:47:30 2008
Subject: [cgiapp] Saving Data From Authentication Phase
Message-ID: <20080107194727.292eb6c930850de810cf35869bff7bc4.0969b57ff0.wbe@email.secureserver.net>

I sent this 4 hours ago but didn't see it come back to me.  Did this not get sent out by the mail server?
 
I'm using CGI::Application::Plugin::Session and CGI::Application::Plugin::Authentication.  With CGI::Application::Plugin::Authentication I'm using the Generic driver.

I have an authentication object in my anonymous subroutine ref that I use for authentication with the Generic driver.  The authentication object returns 0 or 1 if the username/password is valid or not.  And I can also ask for the users info after the user is logged in and it returns a hashref.

How can I save this hashref ( $users_hash_ref = $ad_auth->getUserInfo ) of user info and keep it in my Session for all requests where the user is logged in?

Here is some of my code:

sub setup {

  #  setup authentication
  $self->authen->config(
      DRIVER => [ 'Generic', \&my_login ],
      STORE => 'Session',
      LOGIN_RUNMODE => 'login',
      POST_LOGIN_RUNMODE => 'main',
      LOGOUT_RUNMODE => 'login',
  );

}

sub my_login {

  my ($username, $password) = @_;

  #  connect to auth network
  my $ad_auth = MyCompany::ActiveDirectory->new('WINDOWS');

  return 0 if not $ad_auth->login( $username, $password );

  #  how do I store this info in the hash ref so I always have it???
  $users_hash_ref = $ad_auth->getUserInfo;

  retrun 1;

}


Thanks,
Adam

From adam at spatialsystems.org  Mon Jan  7 22:39:59 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Mon Jan  7 22:40:01 2008
Subject: [cgiapp] Saving Data From Authentication Phase
Message-ID: <20080107203959.292eb6c930850de810cf35869bff7bc4.af2ca51e4f.wbe@email.secureserver.net>

Messages don't seem to be getting through the mail list so I'm trying again.

I'm using CGI::Application::Plugin::Session and CGI::Application::Plugin::Authentication.  With CGI::Application::Plugin::Authentication I'm using the Generic driver.

I have an authentication object in my anonymous subroutine ref that I use for authentication with the Generic driver.  The authentication object returns 0 or 1 if the username/password is valid or not.  And I can also ask for the users info after the user is logged in and it returns a hashref.

How can I save this hashref of user info and keep it in my Session for all requests where the user is logged in?

Here is some of my code:

sub setup {

	#  setup authentication
	$self->authen->config(
		DRIVER	=> [ 'Generic', \&my_login ],
		STORE		=> 'Session',
		LOGIN_RUNMODE	=> 'login',
		POST_LOGIN_RUNMODE => 'main',
		LOGOUT_RUNMODE	=> 'login',
	);

}

sub my_login {

	my ($username, $password) = @_;

	#  connect to auth network
	my $ad_auth = MyCompany::ActiveDirectory->new('WINDOWS');

	return 0 if not $ad_auth->login( $username, $password );

	#  how do I store this info in the hash ref so I always have it???
	$users_hash_ref = $ad_auth->getUserInfo;

	retrun 1;

}


Thanks,
Adam

From adam at spatialsystems.org  Tue Jan  8 13:12:31 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Tue Jan  8 13:12:36 2008
Subject: [cgiapp] Saving Data From Authentication Phase
Message-ID: <20080108111231.292eb6c930850de810cf35869bff7bc4.5f249c9b2f.wbe@email.secureserver.net>

I'm using CGI::Application::Plugin::Session and CGI::Application::Plugin::Authentication.  With CGI::Application::Plugin::Authentication I'm using the Generic driver.

I have an authentication object in my anonymous subroutine ref that I use for authentication with the Generic driver.  The authentication object returns 0 or 1 if the username/password is valid or not.  And I can also ask for the users info after the user is logged in and it returns a hashref.

How can I save this hashref ( $users_hash_ref = $ad_auth->getUserInfo ) of user info and keep it in my Session for all requests where the user is logged in?

Here is some of my code:

sub setup {

	#  setup authentication
	$self->authen->config(
		DRIVER => [ 'Generic', \&my_login ],
		STORE => 'Session',
		LOGIN_RUNMODE => 'login',
		POST_LOGIN_RUNMODE => 'main',
		LOGOUT_RUNMODE => 'login',
	);

}

sub my_login {

	my ($username, $password) = @_;

	#  connect to auth network
	my $ad_auth = MyCompany::ActiveDirectory->new('WINDOWS');

	return 0 if not $ad_auth->login( $username, $password );

	#  how do I store this info in the hash ref so I always have it???
	$users_hash_ref = $ad_auth->getUserInfo;

	retrun 1;

}


Thanks,
Adam
From perl at rhesa.com  Tue Jan  8 13:42:59 2008
From: perl at rhesa.com (Rhesa Rozendaal)
Date: Tue Jan  8 14:13:15 2008
Subject: [cgiapp] Saving Data From Authentication Phase
In-Reply-To: <20080108111231.292eb6c930850de810cf35869bff7bc4.5f249c9b2f.wbe@email.secureserver.net>
References: <20080108111231.292eb6c930850de810cf35869bff7bc4.5f249c9b2f.wbe@email.secureserver.net>
Message-ID: <4783C433.6020608@rhesa.com>

adam@spatialsystems.org wrote:
> How can I save this hashref ( $users_hash_ref = $ad_auth->getUserInfo ) of user info and keep it in my Session for all requests where the user is logged in?

Isn't that the usual:

  # store it inside &my_login
  $self->session->param( ad_auth_userinfo => $ad_auth->getUserInfo );

  # use it elsewhere
  my $userinfo = $self->session->param( 'ad_auth_userinfo' );


> Here is some of my code:
> 
> sub setup {
> 
> 	#  setup authentication
> 	$self->authen->config(
> 		DRIVER => [ 'Generic', \&my_login ],
> 		STORE => 'Session',
> 		LOGIN_RUNMODE => 'login',
> 		POST_LOGIN_RUNMODE => 'main',
> 		LOGOUT_RUNMODE => 'login',
> 	);
> 
> }

CAP::Authentication also has a authen->username method that you might be able 
to use. It won't have all your AD info, of course, but it might be enough for 
your application.

HTH,
Rhesa


From cub.uanic at gmail.com  Tue Jan  8 14:16:16 2008
From: cub.uanic at gmail.com (Oleg Kostyuk)
Date: Tue Jan  8 14:16:19 2008
Subject: [cgiapp] Saving Data From Authentication Phase
In-Reply-To: <20080107203959.292eb6c930850de810cf35869bff7bc4.af2ca51e4f.wbe@email.secureserver.net>
References: <20080107203959.292eb6c930850de810cf35869bff7bc4.af2ca51e4f.wbe@email.secureserver.net>
Message-ID: <60ef632f0801081116k237bb732n138a8c828c209440@mail.gmail.com>

Hello

> Messages don't seem to be getting through the mail list so I'm trying again.
I can read your messages, so mail list seems to working fine.

> I'm using CGI::Application::Plugin::Session and CGI::Application::Plugin::Authentication.  With CGI::Application::Plugin::Authentication I'm using the Generic driver.
[skipped]
> How can I save this hashref of user info and keep it in my Session for all requests where the user is logged in?
CGI::Application::Plugin::Session uses CGI::Session, so you should
take look to it's documentation
(http://search.cpan.org/perldoc?CGI::Session) - try to search "storing
data in the session" and "retrieving data" in it.

HTH

-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)
From adam at spatialsystems.org  Tue Jan  8 14:32:50 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Tue Jan  8 14:32:52 2008
Subject: [cgiapp] Saving Data From Authentication Phase
Message-ID: <20080108123250.292eb6c930850de810cf35869bff7bc4.15206429b9.wbe@email.secureserver.net>

When I try that in the login coderef passed to the CGI::Application::Plugin::Authentication, I get an error about $self not being an explicit package name.  They only thing that gets passed to the coderef is the username and password, not $self.  I don't see a way to save the AD data to the session from within the \&my_login coderef.

Is there a way to store this into the session without modifying CGI::Application::Plugin::Authorization::Driver::Generic to get $self into the auth coderef?

sub setup {

	#  setup authentication
	$self->authen->config(

		#  here we send coderef \&my_login for login
		DRIVER => [ 'Generic', \&my_login ],
		STORE => 'Session',
		LOGIN_RUNMODE => 'login',
		POST_LOGIN_RUNMODE => 'main',
		LOGOUT_RUNMODE => 'login',
	);

}

sub my_login {

	my ($username, $password) = @_;

	my $ad_auth = MyCompany::ActiveDirectory->new('WINDOWS');

	return 0 if not $ad_auth->login( $username, $password );

	#  how do I store this info in the hash ref so I always have it???
	$users_hash_ref = $ad_auth->getUserInfo;

	#  if I try to store it here using the session, $self doesn't exist
	#  and I don' see a way to get it to exist unless I modify 
	#  CGI::Application::Plugin::Authorization::Driver::Generic.
	#  I'm wondering if there's a differnt way to do this without
	#  modifying the driver

	#  doesn't work, $self not here.
	#$self->session->param( ad_auth_userinfo => $ad_auth->getUserInfo );

	return 1;

}




>-------- Original Message --------
>Subject: Re: [cgiapp] Saving Data From Authentication Phase
>From: Rhesa Rozendaal <perl@rhesa.com>
>Date: Tue, January 08, 2008 12:42 pm
>To: CGI Application <cgiapp@lists.erlbaum.net>
>
>adam@spatialsystems.org wrote:
>> How can I save this hashref ( $users_hash_ref = $ad_auth->getUserInfo ) of user info and keep it in my Session for all requests where the user is logged in?
>
>Isn't that the usual:
>
># store it inside &my_login
>$self->session->param( ad_auth_userinfo => $ad_auth->getUserInfo );
>
># use it elsewhere
>my $userinfo = $self->session->param( 'ad_auth_userinfo' );
>
>
>> Here is some of my code:
>> 
>> sub setup {
>> 
>> # setup authentication
>> $self->authen->config(
>> DRIVER => [ 'Generic', \&my_login ],
>> STORE => 'Session',
>> LOGIN_RUNMODE => 'login',
>> POST_LOGIN_RUNMODE => 'main',
>> LOGOUT_RUNMODE => 'login',
>> );
>> 
>> }
>
>CAP::Authentication also has a authen->username method that you might be able 
>to use. It won't have all your AD info, of course, but it might be enough for 
>your application.
>
>HTH,
>Rhesa
>



From adam at spatialsystems.org  Tue Jan  8 14:45:35 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Tue Jan  8 14:46:01 2008
Subject: [cgiapp] Saving Data From Authentication Phase
Message-ID: <20080108124535.292eb6c930850de810cf35869bff7bc4.7a931d742d.wbe@email.secureserver.net>

I figured it out.  My subroutine needed to be declared in my setup.  It was being declared in the Webapp namespace and not the Webapp::setup namespace.  That's why $self wasn't available for storing it into the session.

Thanks,
Adam


>-------- Original Message --------
>Subject: Re: [cgiapp] Saving Data From Authentication Phase
>From: Rhesa Rozendaal <perl@rhesa.com>
>Date: Tue, January 08, 2008 12:42 pm
>To: CGI Application <cgiapp@lists.erlbaum.net>
>
>adam@spatialsystems.org wrote:
>> How can I save this hashref ( $users_hash_ref = $ad_auth->getUserInfo ) of user info and keep it in my Session for all requests where the user is logged in?
>
>Isn't that the usual:
>
># store it inside &my_login
>$self->session->param( ad_auth_userinfo => $ad_auth->getUserInfo );
>
># use it elsewhere
>my $userinfo = $self->session->param( 'ad_auth_userinfo' );
>
>
>> Here is some of my code:
>>
>> sub setup {
>>
>> # setup authentication
>> $self->authen->config(
>> DRIVER => [ 'Generic', \&my_login ],
>> STORE => 'Session',
>> LOGIN_RUNMODE => 'login',
>> POST_LOGIN_RUNMODE => 'main',
>> LOGOUT_RUNMODE => 'login',
>> );
>>
>> }
>
>CAP::Authentication also has a authen->username method that you might be able
>to use. It won't have all your AD info, of course, but it might be enough for
>your application.
>
>HTH,
>Rhesa
>




##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################



From perl at rhesa.com  Tue Jan  8 14:49:19 2008
From: perl at rhesa.com (Rhesa Rozendaal)
Date: Tue Jan  8 15:36:33 2008
Subject: [cgiapp] Saving Data From Authentication Phase
In-Reply-To: <20080108123250.292eb6c930850de810cf35869bff7bc4.15206429b9.wbe@email.secureserver.net>
References: <20080108123250.292eb6c930850de810cf35869bff7bc4.15206429b9.wbe@email.secureserver.net>
Message-ID: <4783D3BF.10802@rhesa.com>

adam@spatialsystems.org wrote:
> When I try that in the login coderef passed to the CGI::Application::Plugin::Authentication, I get an error about $self not being an explicit package name.  They only thing that gets passed to the coderef is the username and password, not $self.  I don't see a way to save the AD data to the session from within the \&my_login coderef.

D'oh! I completely missed that, you're right.

> Is there a way to store this into the session without modifying CGI::Application::Plugin::Authorization::Driver::Generic to get $self into the auth coderef?

You could wrap &mylogin in a closure:

> sub setup {
> 
> 	#  setup authentication
> 	$self->authen->config(
> 
> 		#  here we send coderef \&my_login for login
> 		DRIVER => [ 'Generic', \&my_login ],

DRIVER => [ 'Generic', sub { return $self->my_login( @_ ) } ],

> 		STORE => 'Session',
> 		LOGIN_RUNMODE => 'login',
> 		POST_LOGIN_RUNMODE => 'main',
> 		LOGOUT_RUNMODE => 'login',
> 	);
> 
> }
> 
> sub my_login {

my $self = shift;

> 	my ($username, $password) = @_;
> 
> 	my $ad_auth = MyCompany::ActiveDirectory->new('WINDOWS');
> 
> 	return 0 if not $ad_auth->login( $username, $password );
> 
> 	#  how do I store this info in the hash ref so I always have it???
> 	$users_hash_ref = $ad_auth->getUserInfo;
> 

  	$self->session->param( ad_auth_userinfo => $users_hash_ref );

> 
> 	return 1;
> 
> }
> 

From ron at savage.net.au  Tue Jan  8 20:40:30 2008
From: ron at savage.net.au (Ron Savage)
Date: Tue Jan  8 20:39:57 2008
Subject: [cgiapp] [OT] Seeking software
Message-ID: <1199842830.4545.14.camel@zoe.savage.net.au>

Hi Folks

I'm doing some voluntary work for a community group who have 2
requirements:

o A contacts (e.g. suppliers) manager. Simple, really

o A clients manager. This is complex, with clients getting govt
benefits, housing, etc. So the software has to manage case notes, family
relationships, etc.

Any suggestions welcome.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From dan.horne at redbone.co.nz  Tue Jan  8 21:08:52 2008
From: dan.horne at redbone.co.nz (Dan Horne)
Date: Tue Jan  8 21:08:56 2008
Subject: [cgiapp] [OT] Seeking software
In-Reply-To: <1199842830.4545.14.camel@zoe.savage.net.au>
References: <1199842830.4545.14.camel@zoe.savage.net.au>
Message-ID: <17932.210.54.245.44.1199844532.squirrel@mail.redbone.co.nz>

I'd look at SugarCRM. It works pretty well out of the box, but is also
very customisable

Ron Savage said:
> Hi Folks
>
> I'm doing some voluntary work for a community group who have 2
> requirements:
>
> o A contacts (e.g. suppliers) manager. Simple, really
>
> o A clients manager. This is complex, with clients getting govt
> benefits, housing, etc. So the software has to manage case notes, family
> relationships, etc.
>
> Any suggestions welcome.
> --
> Ron Savage
> ron@savage.net.au
> http://savage.net.au/index.html
>
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>


From adam at spatialsystems.org  Fri Jan 11 02:22:15 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Fri Jan 11 02:22:16 2008
Subject: [cgiapp] How to integrate a module ?
Message-ID: <20080111002215.292eb6c930850de810cf35869bff7bc4.5fc70de8f9.wbe@email.secureserver.net>

SUMMARY:
How should I integrate my OO module with CGI::Application?  Need advice and direction.



Details:
Here is my first OO module ( Tools::User ) that administers users on my system.

Creates a user object populated with user info from DB:
my $user = Tools::User->new( $user_id );

Get info for user stored in db:
my $name = $user->name;

Store info into object and save to db:
$user->name( $new_name );

Check if a user exists:
Tools::User->exists( $user_id ) or die "User $user_id doesn't exist";

Create new user and return object for user:
my $user = Tools::User->insert({ id => 007, name => Bond });



QUESTION:
How should I integrate this with CGI::Application and CGI::Application::Plugin::Authentication?



IMPLEMENTATION:
When a user logs in, Plugin::Authentication stores the User_Id in the session.  I'd like to take
that User_Id and run it in Tools::User->exists( $user_id ) and if it comes back false, then
redirect to a registration page where the user will get created on my system.

If the user already exists in my DB, then I want to load the info for them from my database and
have my user object avail from $self->user in my CGI::Application.



I'd like functionality similar to:


package Tools::Avail::WebApp;
use strict;

use base qw( CGI::Application);

use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::Forward;
use CGI::Application::Plugin::Authentication;
use My::ActiveDirectory;

sub setup {
	my $self = shift;

	$self->start_mode('login');
	$self->mode_param('rm');
	$self->run_modes(
		'login' 	=> 'show_login',
		'main' 		=> 'show_main',
		'register'	=> 'show_register',
	);

	#  setup authentication
	$self->authen->config(
		DRIVER	=> [ 'Generic', \&login ],
		STORE			=> 'Session',
		LOGIN_RUNMODE	=> 'login',
		POST_LOGIN_RUNMODE => 'main',
		LOGOUT_RUNMODE	=> 'login',
	);

	$self->authen->protected_runmodes( 'main' );

	sub login {

		my ( $username, $password ) = @_;
		my $ad_auth = My::ActiveDirectory->new('WIN');

		return 0 if not $ad_auth->login( $username, $password );

		$self->session->param( ad_auth_userinfo => $ad_auth->getUserInfo );


		#########################################################################
		#                                                                 	#
		#  if we've never seen the user before, redirect them to register	#
		#								#
	  	#  if they are already in the DB, then load their data with 		#
		#  Tools::User object that will be accessable everywhere via		#
		#  $self->user							#
		#								#
		#########################################################################

		Tools::User->exists( %{ $self->session->param('ad_auth_userinfo') }->{user_id} } )
			or $self->forward('register');

		return $username;

	}


}


sub show_main {

	my $self = shift;

	#########################################################################
	#								#
	#  retrieve user info, update user info, add user via class method	#
	#  from Tools::Users, how do I implement this functionality?		#
	#								#
	#########################################################################


	#  retrieve user info
	my $name = $self->users->name


	#  update user info
	$self->user->name('New_Name');

	#  class method to see if user exists
	$self->user->exists( $user_id ) or die "user doesn't exist";


	#  create new user and get it's object, don't know if this is necessary for me to do.
	my $new_user_object = $self->user->insert({ id => 007, name => Bond });

}
From adam at spatialsystems.org  Fri Jan 11 12:46:09 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Fri Jan 11 12:46:53 2008
Subject: [cgiapp] How to integrate a module?
Message-ID: <20080111104609.292eb6c930850de810cf35869bff7bc4.9b68764a01.wbe@email.secureserver.net>

SUMMARY:
How should I integrate my OO module with CGI::Applcaiton?



Details:
Here is my first OO module ( Tools::User ) that administers users on my system.

Create a user object populated with user info from DB:
my $user = Tools::User->new( $user_id );

Get info for user stored in db:
my $name = $user->name;

Store info into object and save to db:
$user->name( $new_name );

Check if a user exists:
Tools::User->exists( $user_id ) or die "User $user_id doesn't exist";

Create new user and return object for user:
my $user = Tools::User->insert({ id => 007, name => Bond });



QUESION:
How should I integrate this with CGI::Application and CGI::Application::Plugin::Authentication?



IMPLEMENTATION:
When a user logs in, Plugin::Authentication stores the User_Id in the session.  I'd like to take 
that User_Id and run it in Tools::User->exists( $user_id ) and if it comes back false, then 
redirect to a registration page where the user will get created on my system.

If the user already exists in my DB, then I want to load the info for them from my database and 
have my user object avail from $self->user in my CGI::Application.



I'd like functionality similar to:


package VzTools::CellAvail::WebApp;
use strict;

use base qw( CGI::Application);

use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::Forward;
use CGI::Application::Plugin::Authentication;
use My::ActiveDirectory;
 
sub setup {
	my $self = shift;

	$self->start_mode('login');
	$self->mode_param('rm');
	$self->run_modes(
		'login' 	=> 'show_login',
		'main' 		=> 'show_main',
		'register'	=> 'show_register',
	);

	#  setup authentication
	$self->authen->config(
		DRIVER	=> [ 'Generic', \&login ],
		STORE			=> 'Session',
		LOGIN_RUNMODE	=> 'login',
		POST_LOGIN_RUNMODE => 'main',
		LOGOUT_RUNMODE	=> 'login',
	);	

	$self->authen->protected_runmodes( 'main' );

	$self->tmpl_path('templates');

	$self->add_callback( 'load_tmpl', \&load_template_callback );

	sub login {
	
		my ( $username, $password ) = @_; 
		my $ad_auth = My::ActiveDirectory->new('WIN');
	
		return 0 if not $ad_auth->login( $username, $password );
	
		$self->session->param( ad_auth_userinfo => $ad_auth->getUserInfo );

		
		#########################################################################	
		#                                                                 	#
		#  if we've never seen the user before, redirect them to register	#
		#								#
	  	#  if they are already in the DB, then load their data with 		#
		#  Tools::User object that will be accessable everywhere via		#
		#  $self->user							#
		#								#
		#########################################################################

		Tools::User->exists( %{ $self->session->param('ad_auth_userinfo') }->{user_id} } )
			or $self->forward('register');
		
		return $username;	
	
	}

    
}


sub show_main {

	my $self = shift;

	#########################################################################
	#								#
	#  retrieve user info, update user info, add user via class method	#
	#  from Tools::Users						#
	#								#
	#########################################################################


	#  retrieve user info
	my $name = $self->users->name


	#  update user info
	$self->user->name('New_Name');

	#  class method to see if user exists
	$self->user->exists( $user_id ) or die "user doesn't exist";


	#  create new user and get it's object, dont't know if this is necessary for me to do.
	my $new_user_object = $self->user->insert({ id => 007, name => Bond });

}
From adam at spatialsystems.org  Fri Jan 11 12:27:01 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Fri Jan 11 12:53:44 2008
Subject: [cgiapp] How to integrate a module?
Message-ID: <20080111102701.292eb6c930850de810cf35869bff7bc4.0b7270a5b4.wbe@email.secureserver.net>

SUMMARY:
How should I integrate my OO module with CGI::Applcaiton?



Details:
Here is my first OO module ( Tools::Users ) that administers users on my system.

Create a user object populated with user info from DB:
my $user = Tools::User->new( $user_id );

Get info for user stored in db:
my $name = $user->name;

Store info into object and save to db:
$user->name( $new_name );

Check if a user exists:
Tools::User->exists( $user_id ) or die "User $user_id doesn't exist";

Create new user and return object for user:
my $user = Tools::User->insert({ id => 007, name => Bond });



QUESION:
How should I integrate this with CGI::Application and CGI::Application::Plugin::Authentication?



IMPLEMENTATION:
When a user logs in, Plugin::Authentication stores the User_Id in the session.  I'd like to take 
that User_Id and run it in Tools::User->exists( $user_id ) and if it comes back false, then 
redirect to a registration page where the user will get created on my system.

If the user already exists in my DB, then I want to load the info for them from my database and 
have my user object avail from $self->user in my CGI::Application.



I'd like functionality similar to:


package VzTools::CellAvail::WebApp;
use strict;

use base qw( CGI::Application);

use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::Forward;
use CGI::Application::Plugin::Authentication;
use My::ActiveDirectory;
 
sub setup {
	my $self = shift;

	$self->start_mode('login');
	$self->mode_param('rm');
	$self->run_modes(
		'login' 	=> 'show_login',
		'main' 		=> 'show_main',
		'register'	=> 'show_register',
	);

	#  setup authentication
	$self->authen->config(
		DRIVER	=> [ 'Generic', \&login ],
		STORE			=> 'Session',
		LOGIN_RUNMODE	=> 'login',
		POST_LOGIN_RUNMODE => 'main',
		LOGOUT_RUNMODE	=> 'login',
	);	

	$self->authen->protected_runmodes( 'main' );

	$self->tmpl_path('templates');

	$self->add_callback( 'load_tmpl', \&load_template_callback );

	sub login {
	
		my ( $username, $password ) = @_; 
		my $ad_auth = My::ActiveDirectory->new('WIN');
	
		return 0 if not $ad_auth->login( $username, $password );
	
		$self->session->param( ad_auth_userinfo => $ad_auth->getUserInfo );

		
		#########################################################################	
		#                                                                 	#
		#  if we've never seen the user before, redirect them to register	#
		#								#
	  	#  if they are already in the DB, then load their data with 		#
		#  Tools::User object that will be accessable everywhere via		#
		#  $self->user							#
		#								#
		#########################################################################

		Tools::User->exists( %{ $self->session->param('ad_auth_userinfo') }->{user_id} } )
			or $self->forward('register');
		
		return $username;	
	
	}

    
}


sub show_main {

	my $self = shift;

	#########################################################################
	#								#
	#  retrieve user info, update user info, add user via class method	#
	#  from Tools::Users						#
	#								#
	#########################################################################


	#  retrieve user info
	my $name = $self->users->name


	#  update user info
	$self->user->name('New_Name');

	#  class method to see if user exists
	$self->user->exists( $user_id ) or die "user doesn't exist";


	#  create new user and get it's object, dont't know if this is necessary for me to do.
	my $new_user_object = $self->user->insert({ id => 007, name => Bond });

}
From shijialeee at yahoo.com  Fri Jan 11 19:39:48 2008
From: shijialeee at yahoo.com (James.Q.L)
Date: Fri Jan 11 19:39:50 2008
Subject: [cgiapp] How to integrate a module?
In-Reply-To: <20080111104609.292eb6c930850de810cf35869bff7bc4.9b68764a01.wbe@email.secureserver.net>
Message-ID: <491368.75624.qm@web50112.mail.re2.yahoo.com>

sorry, didn't have time to read through your email. 

you should check out the wiki, this page maybe help http://www.cgi-app.org/index.cgi?OrganizeApp
also search the list archive as this is a question asked few times before.

James.

--- adam@spatialsystems.org wrote:

> SUMMARY:
> How should I integrate my OO module with CGI::Applcaiton?
> 
> 
> 
> Details:
> Here is my first OO module ( Tools::User ) that administers users on my system.
> 
> Create a user object populated with user info from DB:
> my $user = Tools::User->new( $user_id );
> 
> Get info for user stored in db:
> my $name = $user->name;
> 
> Store info into object and save to db:
> $user->name( $new_name );
> 
> Check if a user exists:
> Tools::User->exists( $user_id ) or die "User $user_id doesn't exist";
> 
> Create new user and return object for user:
> my $user = Tools::User->insert({ id => 007, name => Bond });
> 
> 
> 
> QUESION:
> How should I integrate this with CGI::Application and CGI::Application::Plugin::Authentication?
> 
> 
> 
> IMPLEMENTATION:
> When a user logs in, Plugin::Authentication stores the User_Id in the session.  I'd like to take
> 
> that User_Id and run it in Tools::User->exists( $user_id ) and if it comes back false, then 
> redirect to a registration page where the user will get created on my system.
> 
> If the user already exists in my DB, then I want to load the info for them from my database and 
> have my user object avail from $self->user in my CGI::Application.
> 
> 
> 
> I'd like functionality similar to:
> 
> 
> package VzTools::CellAvail::WebApp;
> use strict;
> 
> use base qw( CGI::Application);
> 
> use CGI::Application::Plugin::Session;
> use CGI::Application::Plugin::Forward;
> use CGI::Application::Plugin::Authentication;
> use My::ActiveDirectory;
>  
> sub setup {
> 	my $self = shift;
> 
> 	$self->start_mode('login');
> 	$self->mode_param('rm');
> 	$self->run_modes(
> 		'login' 	=> 'show_login',
> 		'main' 		=> 'show_main',
> 		'register'	=> 'show_register',
> 	);
> 
> 	#  setup authentication
> 	$self->authen->config(
> 		DRIVER	=> [ 'Generic', \&login ],
> 		STORE			=> 'Session',
> 		LOGIN_RUNMODE	=> 'login',
> 		POST_LOGIN_RUNMODE => 'main',
> 		LOGOUT_RUNMODE	=> 'login',
> 	);	
> 
> 	$self->authen->protected_runmodes( 'main' );
> 
> 	$self->tmpl_path('templates');
> 
> 	$self->add_callback( 'load_tmpl', \&load_template_callback );
> 
> 	sub login {
> 	
> 		my ( $username, $password ) = @_; 
> 		my $ad_auth = My::ActiveDirectory->new('WIN');
> 	
> 		return 0 if not $ad_auth->login( $username, $password );
> 	
> 		$self->session->param( ad_auth_userinfo => $ad_auth->getUserInfo );
> 
> 		
> 		#########################################################################	
> 		#                                                                 	#
> 		#  if we've never seen the user before, redirect them to register	#
> 		#								#
> 	  	#  if they are already in the DB, then load their data with 		#
> 		#  Tools::User object that will be accessable everywhere via		#
> 		#  $self->user							#
> 		#								#
> 		#########################################################################
> 
> 		Tools::User->exists( %{ $self->session->param('ad_auth_userinfo') }->{user_id} } )
> 			or $self->forward('register');
> 		
> 		return $username;	
> 	
> 	}
> 
>     
> }
> 
> 
> sub show_main {
> 
> 	my $self = shift;
> 
> 	#########################################################################
> 	#								#
> 	#  retrieve user info, update user info, add user via class method	#
> 	#  from Tools::Users						#
> 	#								#
> 	#########################################################################
> 
> 
> 	#  retrieve user info
> 	my $name = $self->users->name
> 
> 
> 	#  update user info
> 	$self->user->name('New_Name');
> 
> 	#  class method to see if user exists
> 	$self->user->exists( $user_id ) or die "user doesn't exist";
> 
> 
> 	#  create new user and get it's object, dont't know if this is necessary for me to do.
> 	my $new_user_object = $self->user->insert({ id => 007, name => Bond });
> 
> }
> 
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
> 
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

From trwww at sbcglobal.net  Sat Jan 12 13:26:45 2008
From: trwww at sbcglobal.net (Todd W)
Date: Sat Jan 12 13:26:50 2008
Subject: [cgiapp] How to integrate a module ?
References: <20080111002215.292eb6c930850de810cf35869bff7bc4.5fc70de8f9.wbe@email.secureserver.net>
Message-ID: <002401c85548$b1809760$5402a8c0@trwlapgateway>


From: <adam@spatialsystems.org>

> QUESTION:
> How should I integrate this with CGI::Application and 
> CGI::Application::Plugin::Authentication?

You could check out my slides from yapc 07. Half of them are Catalyst, but 
the half that are CGI::App cover this exact thing:

http://www.waveright.com/yapc07/
http://www.waveright.com/svn/yapc/yapc07/trunk/cgiapp/MyStore

Also, I found the ::Plugin::Authentication documentation very helpful.

trwww

From trwww at sbcglobal.net  Sun Jan 13 01:55:09 2008
From: trwww at sbcglobal.net (Todd W)
Date: Sun Jan 13 01:55:14 2008
Subject: [Bulk] [cgiapp] How to integrate a module ?
References: <20080111002215.292eb6c930850de810cf35869bff7bc4.5fc70de8f9.wbe@email.secureserver.net>
Message-ID: <00e701c855b1$3df8b160$5402a8c0@trwlapgateway>


From: <adam@spatialsystems.org>

> QUESTION:
> How should I integrate this with CGI::Application and 
> CGI::Application::Plugin::Authentication?

You could check out my slides from yapc 07. Half of them are Catalyst, but 
the half that are CGI::App cover this exact thing:

http://www.waveright.com/yapc07/
http://www.waveright.com/svn/yapc/yapc07/trunk/cgiapp/MyStore

Also, I found the ::Plugin::Authentication documentation very helpful.

trwww

From adam at spatialsystems.org  Sun Jan 13 23:22:33 2008
From: adam at spatialsystems.org (adam@spatialsystems.org)
Date: Sun Jan 13 23:22:36 2008
Subject: [cgiapp] Displaying LoggedIn or Login
Message-ID: <20080113212233.292eb6c930850de810cf35869bff7bc4.561fb30921.wbe@email.secureserver.net>

I'm using HTML::Template and I have a block of HTML that will either display "Logged In" or "Not Logged In" based on if I'm logged in or not.

<div>
  <div>Logged In</div>
</div>

OR

<div>
  <div>Not Logged In</div>
</div>


How should I implement showing one of either block depending if I'm logged in?


My thought is to register a template callback to figure out if I'm logged in and pass HTML::Template a boolean for <TMPL_IF>


Something like this:
<TMPL_IF NAME="LOGGEDIN">
  <div>
    <div>Logged In</div>
  </div>
</TMPL_IF>

<TMPL_IF NAME="LOGGEDIN">
  <div>
    <div>Not Logged In</div>
  </div>
</TMPL_IF>


Does this sound right or is there a better way?

Thanks,
Adam
From ron at savage.net.au  Mon Jan 14 00:22:59 2008
From: ron at savage.net.au (Ron Savage)
Date: Mon Jan 14 00:23:55 2008
Subject: [cgiapp] Displaying LoggedIn or Login
In-Reply-To: <20080113212233.292eb6c930850de810cf35869bff7bc4.561fb30921.wbe@email.secureserver.net>
References: <20080113212233.292eb6c930850de810cf35869bff7bc4.561fb30921.wbe@email.secureserver.net>
Message-ID: <1200288179.868.1.camel@zoe.savage.net.au>

On Sun, 2008-01-13 at 21:22 -0700, adam@spatialsystems.org wrote:

Hi Adam

Something like this:

  <div>
    <div><TMPL_IF NAME="LOGGEDIN">Logged In<tmpl_else>Not Logged In</TMPL_IF></div>
  </div>

looks simpler.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From adrianh at quietstars.com  Tue Jan 15 06:42:13 2008
From: adrianh at quietstars.com (Adrian Howard)
Date: Tue Jan 15 06:42:25 2008
Subject: [cgiapp] [request] Hardware for Smolder
In-Reply-To: <476B453C.50906@plusthree.com>
References: <476B453C.50906@plusthree.com>
Message-ID: <29A3EDDA-1554-4CFC-8E14-5E4B50DEE989@quietstars.com>

Got anything for this yet?

(not nagging - just seeing if it's still appropriate for me to do  
some begging :-)

Cheers,

Adrian


On 21 Dec 2007, at 04:46, Michael Peters wrote:

> As part of a TPF Grant that I'm working on, the last thing I need  
> to do is setup
> a Smolder (http://sourceforge.net/projects/smolder) server for  
> receiving test
> reports for CGI::App CPAN modules. There's also talk about trying  
> to hook into
> CPAN's smoke testing service so that you can receive more detailed  
> reports
> instead of the particularly vague emails that come from CPANTS  
> boxes...
>
> Smolder doesn't take a lot of resources (it can use MySQL if it's  
> installed or
> just use SQLite locally. If this becomes popular for other CPAN  
> authors then
> disk space might be an issue eventually, but not anytime soon...
>
> Any donors?
>
> -- 
> Michael Peters
> Developer
> Plus Three, LP
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

From stephen.carville at gmail.com  Wed Jan 16 14:06:05 2008
From: stephen.carville at gmail.com (Stephen Carville)
Date: Wed Jan 16 14:07:29 2008
Subject: [cgiapp] Settng Template path
Message-ID: <2428c0380801161106q28343dddi975a9704f08aeb96@mail.gmail.com>

I'm trying out CGI++Application plus HTML::Template as a
replacement/upgrade for a current report generation system but I'm
havinmg a problem with settng the template path:

I create a module called DailyFloodSummary.pm:

 #!/usr/bin/perl
 package DailyFloodSummary;
 use base 'CGI::Application';
 use strict;
 use warnings;
 use HTML::Template;

 # Constants
 my $TMPL_DIR = "/var/www/perl/html_templates";

 #######################################
 # Setup
 #
 sub setup {
   my $self = shift;

   $self->tmpl_path($TMPL_DIR);
   $self->run_modes(
      '0' => 'show_search_form',
      '1' => 'show_results_list'
   );

   $self->start_mode('0');

   $self->mode_param('level');
 }

 #######################################
 # show the search form
 #
 sub show_search_form {
   my $self = shift;
   my ($cgi,$date,$time);
   my ($header,$body,$trailer,$output);

   # open the header template
   $header = $self->load_tmpl("header.tmpl");

   # current date and time from library routines
   ($date,$time) = web_get_today();

   $header->param(todaysdate => "$date $time");

   $output = $header->output;

   return $output;
 }

I call it from dfs.cgi

#!/usr/bin/perl

use strict;
use warnings;

use lib ".";
use DailyFloodSummary;

my $app = DailyFloodSummary->new();

$app->run();

I get the following error list:

Error executing run mode '0': HTML::Template->new() : Cannot open
included file header.tmpl : file not found. at
/usr/lib/perl5/site_perl/5.8.8/HTML/Template.pm line 1658
        HTML::Template::_init_template('HTML::Template=HASH(0x1f738f80)')
called at /usr/lib/perl5/site_perl/5.8.8/HTML/Template.pm line 1238
        HTML::Template::_init('HTML::Template=HASH(0x1f738f80)')
called at /usr/lib/perl5/site_perl/5.8.8/HTML/Template.pm line 1124
        HTML::Template::new('HTML::Template', 'filename',
'header.tmpl', 'path', 'ARRAY(0x1f83f1a0)') called at
/usr/lib/perl5/site_perl/5.8.8/HTML/Template.pm line 1182
        HTML::Template::new_file('HTML::Template', 'header.tmpl',
'path', 'ARRAY(0x1f83f1a0)') called at
/usr/lib/perl5/site_perl/5.8.8/CGI/Application.pm line 1464
        CGI::Application::load_tmpl('DailyFloodSummary=HASH(0x1f5e12e0)',
'header.tmpl') called at DailyFloodSummary.pm line 40
        DailyFloodSummary::show_search_form('DailyFloodSummary=HASH(0x1f5e12e0)')
called at /usr/lib/perl5/site_perl/5.8.8/CGI/Application.pm line 152
        eval {...} called at
/usr/lib/perl5/site_perl/5.8.8/CGI/Application.pm line 151
        CGI::Application::run('DailyFloodSummary=HASH(0x1f5e12e0)')
called at ./dfs.cgi line 11
 at ./dfs.cgi line 11

Any idea what I am doing wrong?

-- 
Stephen Carville
From stephen.carville at gmail.com  Wed Jan 16 14:43:48 2008
From: stephen.carville at gmail.com (Stephen Carville)
Date: Wed Jan 16 14:43:51 2008
Subject: [cgiapp] Re: Settng Template path
In-Reply-To: <2428c0380801161106q28343dddi975a9704f08aeb96@mail.gmail.com>
References: <2428c0380801161106q28343dddi975a9704f08aeb96@mail.gmail.com>
Message-ID: <2428c0380801161143u4e89eaap6a9d23fd06f03178@mail.gmail.com>

Forget it!  False alarm!

"html_templates" should be "html-templates".

On Jan 16, 2008 11:06 AM, Stephen Carville <stephen.carville@gmail.com> wrote:
> I'm trying out CGI++Application plus HTML::Template as a
> replacement/upgrade for a current report generation system but I'm
> havinmg a problem with settng the template path:
>
> I create a module called DailyFloodSummary.pm:
>
>  #!/usr/bin/perl
>  package DailyFloodSummary;
>  use base 'CGI::Application';
>  use strict;
>  use warnings;
>  use HTML::Template;
>
>  # Constants
>  my $TMPL_DIR = "/var/www/perl/html_templates";
>
>  #######################################
>  # Setup
>  #
>  sub setup {
>    my $self = shift;
>
>    $self->tmpl_path($TMPL_DIR);
>    $self->run_modes(
>       '0' => 'show_search_form',
>       '1' => 'show_results_list'
>    );
>
>    $self->start_mode('0');
>
>    $self->mode_param('level');
>  }
>
>  #######################################
>  # show the search form
>  #
>  sub show_search_form {
>    my $self = shift;
>    my ($cgi,$date,$time);
>    my ($header,$body,$trailer,$output);
>
>    # open the header template
>    $header = $self->load_tmpl("header.tmpl");
>
>    # current date and time from library routines
>    ($date,$time) = web_get_today();
>
>    $header->param(todaysdate => "$date $time");
>
>    $output = $header->output;
>
>    return $output;
>  }
>
> I call it from dfs.cgi
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use lib ".";
> use DailyFloodSummary;
>
> my $app = DailyFloodSummary->new();
>
> $app->run();
>
> I get the following error list:
>
> Error executing run mode '0': HTML::Template->new() : Cannot open
> included file header.tmpl : file not found. at
> /usr/lib/perl5/site_perl/5.8.8/HTML/Template.pm line 1658
>         HTML::Template::_init_template('HTML::Template=HASH(0x1f738f80)')
> called at /usr/lib/perl5/site_perl/5.8.8/HTML/Template.pm line 1238
>         HTML::Template::_init('HTML::Template=HASH(0x1f738f80)')
> called at /usr/lib/perl5/site_perl/5.8.8/HTML/Template.pm line 1124
>         HTML::Template::new('HTML::Template', 'filename',
> 'header.tmpl', 'path', 'ARRAY(0x1f83f1a0)') called at
> /usr/lib/perl5/site_perl/5.8.8/HTML/Template.pm line 1182
>         HTML::Template::new_file('HTML::Template', 'header.tmpl',
> 'path', 'ARRAY(0x1f83f1a0)') called at
> /usr/lib/perl5/site_perl/5.8.8/CGI/Application.pm line 1464
>         CGI::Application::load_tmpl('DailyFloodSummary=HASH(0x1f5e12e0)',
> 'header.tmpl') called at DailyFloodSummary.pm line 40
>         DailyFloodSummary::show_search_form('DailyFloodSummary=HASH(0x1f5e12e0)')
> called at /usr/lib/perl5/site_perl/5.8.8/CGI/Application.pm line 152
>         eval {...} called at
> /usr/lib/perl5/site_perl/5.8.8/CGI/Application.pm line 151
>         CGI::Application::run('DailyFloodSummary=HASH(0x1f5e12e0)')
> called at ./dfs.cgi line 11
>  at ./dfs.cgi line 11
>
> Any idea what I am doing wrong?
>
> --
> Stephen Carville
>



-- 
Stephen Carville
From sigzero at gmail.com  Wed Jan 16 21:10:49 2008
From: sigzero at gmail.com (Robert Hicks)
Date: Wed Jan 16 21:11:01 2008
Subject: [cgiapp] Task::CGIApp
Message-ID: <fmmdfa$pal$1@ger.gmane.org>

I was reading the CA website and saw the post that it would be nice to 
have a Task::CGIApp. What would be the list of recommended plugins that 
you would like to see loaded from Task::CGIApp?

Robert

From ron at savage.net.au  Sat Jan 19 23:33:52 2008
From: ron at savage.net.au (Ron Savage)
Date: Sat Jan 19 23:33:12 2008
Subject: [cgiapp] Combining CGI::App::Plugin::Apache and CGI::App::Dispatch
Message-ID: <1200803632.868.64.camel@zoe.savage.net.au>

Hi Folks

Is is possible to combine the 2 modules named in the Subject?

Context is:

o Debian etch

o Apache/2.2.6 (Unix) mod_fastcgi/2.4.6 mod_apreq2-20051231/2.6.0
mod_perl/2.0.3 Perl/v5.8.8 configured

What I'm finding is:

o I can use CGI::App::Dispatch by itself

o When I add CGI::App::Plugin::Apache, CGI::App::Dispatch is disabled,
so CGI::App calls its default sub setup(), and the default run mode
'start' triggers a call to CGI::App's sub dump_html(), but since the
query object is now an Apache::Request object, which has no sub Dump(),
CGI::App is dying at line 297:
	$output .= $query->Dump;
The full error msg is:
[Sun Jan 20 15:26:56 2008] [error] [client 127.0.0.1] Error executing
run mode 'start': Can't locate auto/Apache2/Request/Dump.al in @INC
(@INC
contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . /home/ron/httpd/prefork) at /usr/local/share/perl/5.8.8/CGI/Application.pm line 297\n at /usr/local/share/perl/5.8.8/CGI/Application/Plugin/Apache.pm line 36\n

-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From trwww at sbcglobal.net  Sun Jan 20 09:26:54 2008
From: trwww at sbcglobal.net (Todd W)
Date: Sun Jan 20 09:26:57 2008
Subject: [cgiapp] Task::CGIApp
References: <fmmdfa$pal$1@ger.gmane.org>
Message-ID: <006c01c85b70$82e35360$5402a8c0@trwlapgateway>


From: "Robert Hicks" <sigzero@gmail.com>

>I was reading the CA website and saw the post that it would be nice to 
> have a Task::CGIApp. What would be the list of recommended plugins that 
> you would like to see loaded from Task::CGIApp?

Just a few of my faves:

::Plugin::Session
::Plugin::Stash
::Plugin::TT
::Plugin::Authorization
::Plugin::Authenticication
::Plugin::ValidateRM
::Plugin::DBH
::Plugin::AutoRunmode
::Dispatch
::Plugin::RateLimit
::Plugin::RequireSSL

:-)

trwww

From adrianh at quietstars.com  Sun Jan 20 14:21:49 2008
From: adrianh at quietstars.com (Adrian Howard)
Date: Sun Jan 20 14:21:57 2008
Subject: [cgiapp] [request] Hardware for Smolder
In-Reply-To: <29A3EDDA-1554-4CFC-8E14-5E4B50DEE989@quietstars.com>
References: <476B453C.50906@plusthree.com>
	<29A3EDDA-1554-4CFC-8E14-5E4B50DEE989@quietstars.com>
Message-ID: <EAC55C62-6DDD-404D-9A23-C2CF77A864B1@quietstars.com>


On 15 Jan 2008, at 11:42, Adrian Howard wrote:

> Got anything for this yet?
>
> (not nagging - just seeing if it's still appropriate for me to do  
> some begging :-)

Guess who didn't mean that to go to the whole list :-/

Adrian

From karen.cravens at gmail.com  Sun Jan 20 14:24:54 2008
From: karen.cravens at gmail.com (Karen)
Date: Sun Jan 20 14:24:58 2008
Subject: [cgiapp] [request] Hardware for Smolder
In-Reply-To: <EAC55C62-6DDD-404D-9A23-C2CF77A864B1@quietstars.com>
References: <476B453C.50906@plusthree.com>
	<29A3EDDA-1554-4CFC-8E14-5E4B50DEE989@quietstars.com>
	<EAC55C62-6DDD-404D-9A23-C2CF77A864B1@quietstars.com>
Message-ID: <7cc7c1ce0801201124u59de97f6occ1d7f9c6af7183d@mail.gmail.com>

On 1/20/08, Adrian Howard <adrianh@quietstars.com> wrote:

> Guess who didn't mean that to go to the whole list :-/

That's okay, I'm curious too.  We're relocating to a new hosting
service on a faster box, and might could find some room if nobody else
has.
From mpeters at plusthree.com  Sun Jan 20 17:13:35 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Sun Jan 20 17:15:21 2008
Subject: [cgiapp] Combining CGI::App::Plugin::Apache and CGI::App::Dispatch
In-Reply-To: <1200803632.868.64.camel@zoe.savage.net.au>
References: <1200803632.868.64.camel@zoe.savage.net.au>
Message-ID: <4793C78F.6040401@plusthree.com>

Ron Savage wrote:

> Is is possible to combine the 2 modules named in the Subject?

Yes, but it depends on how you use them. Are you trying to use both of them as
base classes? Dispatch is not intended to be used as a base class. Dispatch sits
outside of your application modules and *dispatches* to them.

-- 
Michael Peters
Developer
Plus Three, LP

From mpeters at plusthree.com  Sun Jan 20 17:20:44 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Sun Jan 20 17:22:29 2008
Subject: [cgiapp] Re: cgiapp plug JSON.
In-Reply-To: <901549.93348.qm@web32405.mail.mud.yahoo.com>
References: <901549.93348.qm@web32405.mail.mud.yahoo.com>
Message-ID: <4793C93C.7020500@plusthree.com>

Neil Mansilla wrote:
> Hi there,

CC'ing the cgi-app list:

> Can you give me a little tip on how to get the plugin to properly work
> with CGIapp in terms of changing the content-type and sending the data
> out to the application properly? 

It should be pretty straight forward.

> I'm using prototype.js to observe one
> of my form fields and onchange it runs my CGIapp runmode "foo_ajax". 
> I'd like to instruct my CGIapp to use the JSON plugin so that the data
> is properly sent back in as compact way as possible.

Are you trying to send JSON data in the HTTP X-JSON header or as the contents of
the response? If the header, just do:

  $self->json_header(foo => 'bar');

Somewhere in your run mode. If your sending the JSON as the contents of the
response then it's just:

  return $self->json_body({ foo => 'bar' });

at the end of your run mode.

> I'm trying to set the header_type to none, etc.. but I'm just getting a
> lot of Error 500s and other errors from CGIapp.

A 500 error means *look in your server log* :)

-- 
Michael Peters
Developer
Plus Three, LP

From mpeters at plusthree.com  Sun Jan 20 17:43:35 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Sun Jan 20 17:45:19 2008
Subject: [cgiapp] [request] Hardware for Smolder
In-Reply-To: <29A3EDDA-1554-4CFC-8E14-5E4B50DEE989@quietstars.com>
References: <476B453C.50906@plusthree.com>
	<29A3EDDA-1554-4CFC-8E14-5E4B50DEE989@quietstars.com>
Message-ID: <4793CE97.5080900@plusthree.com>

Adrian Howard wrote:
> Got anything for this yet?
> 
> (not nagging - just seeing if it's still appropriate for me to do some
> begging :-)

I've got a lead I'm waiting on. He needed to move some stuff around but was
going to let me know when he was ready.

Thanks for the prodding!

-- 
Michael Peters
Developer
Plus Three, LP

From ron at savage.net.au  Sun Jan 20 18:12:22 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Jan 20 18:13:12 2008
Subject: [cgiapp] Combining CGI::App::Plugin::Apache and CGI::App::Dispatch
In-Reply-To: <4793C78F.6040401@plusthree.com>
References: <1200803632.868.64.camel@zoe.savage.net.au>
	<4793C78F.6040401@plusthree.com>
Message-ID: <1200870742.868.72.camel@zoe.savage.net.au>

On Sun, 2008-01-20 at 17:13 -0500, Michael Peters wrote:

Hi Michael

Thanx for the response.

> > Is is possible to combine the 2 modules named in the Subject?
> 
> Yes, but it depends on how you use them. Are you trying to use both of them as
> base classes? Dispatch is not intended to be used as a base class. Dispatch sits
> outside of your application modules and *dispatches* to them.

Yes, I'm trying to use them both as base classes, as in:
use base qw(CGI::Application CGI::Application::Dispatch);

'... not intended to be used as a base class'??????
Let me quote your Synopsis:
With a dispatch table
    package MyApp::Dispatch;
    use base 'CGI::Application::Dispatch';

No $customized_profanity wonder I'm confused :=).

The Synopsis goes on:
    sub dispatch_args {
        return {
            prefix  => 'MyApp',
            table   => [
                ''                => { app => 'Welcome', rm => 'start' },
                ':app/:rm'        => { },
                'admin/:app/:rm'  => { prefix   => 'MyApp::Admin' },
            ],
        };
    }

So, how will CGI::Application::Dispatch have access to dispatch_args() if that sub is inside my module?

Anyway, thanx for the pointers. I'll battle on while I breathlessly await your reply...
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ron at savage.net.au  Sun Jan 20 18:16:01 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Jan 20 18:15:20 2008
Subject: [cgiapp] Combining CGI::App::Plugin::Apache and CGI::App::Dispatch
In-Reply-To: <4793C78F.6040401@plusthree.com>
References: <1200803632.868.64.camel@zoe.savage.net.au>
	<4793C78F.6040401@plusthree.com>
Message-ID: <1200870961.868.76.camel@zoe.savage.net.au>

On Sun, 2008-01-20 at 17:13 -0500, Michael Peters wrote:

Hi Michael

Ha. More reading of the docs suggests I was labouring under even more of
a mis-understanding than even I'd assumed. I was putting sub
dispatch_args() in my CGI::App-based base class :-(. Sigh.

-- 
Ron (Perhaps I should just retire now) Savage
ron@savage.net.au
http://savage.net.au/index.html


From mpeters at plusthree.com  Mon Jan 21 09:33:20 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Mon Jan 21 09:35:06 2008
Subject: [cgiapp] Combining CGI::App::Plugin::Apache and CGI::App::Dispatch
In-Reply-To: <1200870742.868.72.camel@zoe.savage.net.au>
References: <1200803632.868.64.camel@zoe.savage.net.au>	<4793C78F.6040401@plusthree.com>
	<1200870742.868.72.camel@zoe.savage.net.au>
Message-ID: <4794AD30.9040607@plusthree.com>

Ron Savage wrote:

> Yes, I'm trying to use them both as base classes, as in:
> use base qw(CGI::Application CGI::Application::Dispatch);
> 
> '... not intended to be used as a base class'??????
> Let me quote your Synopsis:
> With a dispatch table
>     package MyApp::Dispatch;
>     use base 'CGI::Application::Dispatch';
> 
> No $customized_profanity wonder I'm confused :=).

You can subclass Dispatch. That's not a problem. I do it all the time. But you
subclass it to create a custom dispatch module, not an application module. For
that you subclass C::A itself. Remember, Dispatch sits outside of your
application modules and dispatches to them. The prime use case is when you have
lots of application modules. For instance, Smolder has 11 application modules
(which inherit from C::A) and 1 dispatch module (which inherits from Dispatch).

-- 
Michael Peters
Developer
Plus Three, LP

From szabgab at gmail.com  Mon Jan 21 21:09:52 2008
From: szabgab at gmail.com (Gabor Szabo)
Date: Mon Jan 21 21:09:54 2008
Subject: [cgiapp] Best practice for dealing with errors during the
	cgiapp_init method
Message-ID: <d8a74af10801211809p3487837bud99a0525760a085a@mail.gmail.com>

As I understand the error_mode should be defined in the setup() phase.
What is the standard way to handle errors during the previous phases,
e.g. during cgiapp_init()?
What if the configuration file read during cgiapp_init is missing or
if the database connection could
not be established?

Right now I have this in my script:

eval {
    $dn = WebApp->new;
    $dn->run;
};
if ($@) {
    warn "Major crisis: $@";
    print "Content-type: text/html\n\n";
    print "Major crisis. Please ask the site administrator to look at
the log files.\n";
}


Any better way to handle this?

Gabor
From szabgab at gmail.com  Mon Jan 21 21:16:55 2008
From: szabgab at gmail.com (Gabor Szabo)
Date: Mon Jan 21 21:17:07 2008
Subject: [cgiapp] slight documentation change
Message-ID: <d8a74af10801211816i4110ffb3x3a75c1e348f9dae2@mail.gmail.com>

Would it be possible to change the the documentation so the order of
the methods one can implement in
the subclass is the same in the documentation as in the order of calling?

Would it be possible to add the hierarchy to the documentation
something like this:

=over 4

=item new

=over 4

=item cgiapp_init()

=item setup()

=back

=item run

=over 4

=item cgiapp_prerun()

=item User implemented run mode

=item cgiapp_postrun()

=item teardown()

=back

=back


Gabor
From ron at savage.net.au  Sun Jan 27 17:57:08 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Jan 27 17:56:23 2008
Subject: [cgiapp] Combining CGI::App::Plugin::Apache and CGI::App::Dispatch
In-Reply-To: <4794AD30.9040607@plusthree.com>
References: <1200803632.868.64.camel@zoe.savage.net.au>
	<4793C78F.6040401@plusthree.com>
	<1200870742.868.72.camel@zoe.savage.net.au>
	<4794AD30.9040607@plusthree.com>
Message-ID: <1201474628.5082.61.camel@zoe.savage.net.au>

On Mon, 2008-01-21 at 09:33 -0500, Michael Peters wrote:

Hi Michael
> You can subclass Dispatch. That's not a problem. I do it all the time. But you

Yes, thanx. I eventually understood what to do...

<===><8===>
package CGI::Application::Test::ModperlDispatcher;

use base 'CGI::Application::Dispatch';
use strict;
use warnings;

our $VERSION = '1.00';

# -----------------------------------------------

sub dispatch_args
{
	return
	{
		prefix => 'CGI::Application::Test::Modperl',
		table  =>
		[
		 ''         => {app => 'main-menu', rm => 'menu'},
		 ':app/:rm' => {},
		],
	};

} # End of dispatch_args.

# -----------------------------------------------

1;
<===><8===>
I.e. Exactly as recommended. The problem was in the understanding, not
in your code. And in httpd.conf:
<===><8===>
<Location /mp>
	SetHandler perl-script
	PerlResponseHandler CGI::Application::Test::ModperlDispatcher
</Location>
<===><8===>
Again, exactly as recommended...

-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From sigzero at gmail.com  Mon Jan 28 21:36:34 2008
From: sigzero at gmail.com (Robert Hicks)
Date: Mon Jan 28 21:36:49 2008
Subject: [cgiapp] CA and AJAX
Message-ID: <fnm3fm$vkm$1@ger.gmane.org>

I am looking at the Ext Js 2.0 AJAX framework and it looks really good 
(I also like jQuery). Is anybody working on an easy way to call Ext 
stuff from Perl through CA?

Robert

From mpeters at plusthree.com  Tue Jan 29 09:29:25 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Tue Jan 29 09:31:23 2008
Subject: [cgiapp] CA and AJAX
In-Reply-To: <fnm3fm$vkm$1@ger.gmane.org>
References: <fnm3fm$vkm$1@ger.gmane.org>
Message-ID: <479F3845.9040101@plusthree.com>

Robert Hicks wrote:
> I am looking at the Ext Js 2.0 AJAX framework and it looks really good
> (I also like jQuery). Is anybody working on an easy way to call Ext
> stuff from Perl through CA?

Ajax stuff is fun to do, but it's really no different from normal web work, at
least from a C::A perspective. You call run modes just the same. It doesn't
matter how the request makes it to the backend. The only real differences are
the following:

+ you almost never return full pages (header, nav, footer, etc). This is pretty
easy to do with templating. I just set a no_wrapper param that goes to my
templates on Ajax requests to turn off the extra stuff I don't need.

+ JSON - If I have any advice about Ajax programming is don't use XML if you can
avoid it. It's nice to be able to read RSS feeds from some other source, but if
you can control the data source use JSON. It's faster, smaller, easier to read
and more "natural" to Perl. Check out C::A::Plugin::JSON for some easy ways to
use it

-- 
Michael Peters
Developer
Plus Three, LP

From hitz at genome.stanford.edu  Tue Jan 29 11:27:45 2008
From: hitz at genome.stanford.edu (Ben Hitz)
Date: Tue Jan 29 12:06:40 2008
Subject: [cgiapp] CA and AJAX
In-Reply-To: <479F3845.9040101@plusthree.com>
References: <fnm3fm$vkm$1@ger.gmane.org> <479F3845.9040101@plusthree.com>
Message-ID: <6311C6CB-0244-47B8-B663-DD7ABB7E52F4@genome.stanford.edu>

I have been starting to interface my CA  with both DBIx::Class and  
the Rico js library (www.openrico.org), which is derived from  
prototype.js.

Generally, I haven't found much use to actually write javascript from  
perl; I prefer to use Templates for the javascript and XML and use  
the perl to define variables and configure.  There is an  
HTML::Prototype library and associated CGI:App plugin.  At one point  
I was looking at jQuery and had to write a 6 line  
Cgi::App::Plugin::jQuery  module (but I never used it).

One thing that tripped me up for a day or two was forgetting to  
escape $ in TT2 so that it appears as $(variable) in javascript.

Ben


On Jan 29, 2008, at 6:29 AM, Michael Peters wrote:

> Robert Hicks wrote:
>> I am looking at the Ext Js 2.0 AJAX framework and it looks really  
>> good
>> (I also like jQuery). Is anybody working on an easy way to call Ext
>> stuff from Perl through CA?
>
> Ajax stuff is fun to do, but it's really no different from normal  
> web work, at
> least from a C::A perspective. You call run modes just the same. It  
> doesn't
> matter how the request makes it to the backend. The only real  
> differences are
> the following:
>
> + you almost never return full pages (header, nav, footer, etc).  
> This is pretty
> easy to do with templating. I just set a no_wrapper param that goes  
> to my
> templates on Ajax requests to turn off the extra stuff I don't need.
>
> + JSON - If I have any advice about Ajax programming is don't use  
> XML if you can
> avoid it. It's nice to be able to read RSS feeds from some other  
> source, but if
> you can control the data source use JSON. It's faster, smaller,  
> easier to read
> and more "natural" to Perl. Check out C::A::Plugin::JSON for some  
> easy ways to
> use it
>
> -- 
> Michael Peters
> Developer
> Plus Three, LP
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################

--
Ben Hitz
Senior Scientific Programmer ** Saccharomyces Genome Database ** GO  
Consortium
Stanford University ** hitz@genome.stanford.edu



From sigzero at gmail.com  Wed Jan 30 17:25:31 2008
From: sigzero at gmail.com (Robert Hicks)
Date: Wed Jan 30 18:11:24 2008
Subject: [cgiapp] Template::TAL
Message-ID: <fnqtgu$n5n$1@ger.gmane.org>

Has anyone tried integrating:

http://search.cpan.org/~fotango/Template-TAL-0.91/lib/Template/TAL.pm

into CA? Looks like a nice fit.

Robert

From mpeters at plusthree.com  Wed Jan 30 18:18:09 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Wed Jan 30 18:21:57 2008
Subject: [cgiapp] Template::TAL
In-Reply-To: <fnqtgu$n5n$1@ger.gmane.org>
References: <fnqtgu$n5n$1@ger.gmane.org>
Message-ID: <47A105B1.5000408@plusthree.com>

Robert Hicks wrote:
> Has anyone tried integrating:
> 
> http://search.cpan.org/~fotango/Template-TAL-0.91/lib/Template/TAL.pm
> 
> into CA? Looks like a nice fit.

It's just another templating system. The only real reason to use TAL is because
it's language agnostic. It's got implementations in Python, Java and PHP. So if
you're working on a multi language project then it's a good fit. Otherwise it's
slow (slower than both TT and H::T) and I find it incredibly verbose and clumsy.
I converted a few TAL templates into TT equivalents once and the reduction in
size was almost 50%.

-- 
Michael Peters
Developer
Plus Three, LP

From sigzero at gmail.com  Wed Jan 30 21:46:12 2008
From: sigzero at gmail.com (Robert Hicks)
Date: Wed Jan 30 21:46:34 2008
Subject: [cgiapp] Re: Template::TAL
In-Reply-To: <47A105B1.5000408@plusthree.com>
References: <fnqtgu$n5n$1@ger.gmane.org> <47A105B1.5000408@plusthree.com>
Message-ID: <fnrcpo$f0$1@ger.gmane.org>

Michael Peters wrote:
> Robert Hicks wrote:
>> Has anyone tried integrating:
>>
>> http://search.cpan.org/~fotango/Template-TAL-0.91/lib/Template/TAL.pm
>>
>> into CA? Looks like a nice fit.
> 
> It's just another templating system. The only real reason to use TAL is because
> it's language agnostic. It's got implementations in Python, Java and PHP. So if
> you're working on a multi language project then it's a good fit. Otherwise it's
> slow (slower than both TT and H::T) and I find it incredibly verbose and clumsy.
> I converted a few TAL templates into TT equivalents once and the reduction in
> size was almost 50%.
> 
Good enough for me *not* to use it. Thanks for the input.

Robert

From mpeters at plusthree.com  Thu Jan 31 14:46:43 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Thu Jan 31 14:48:43 2008
Subject: [cgiapp] Re: Dispatcher
In-Reply-To: <dd98d4b4ff6e.47a1ddca@gwu.edu>
References: <dd98d4b4ff6e.47a1ddca@gwu.edu>
Message-ID: <47A225A3.8040202@plusthree.com>

Karunakar Komirishetty wrote:
> Hello Michael

CC'ing the C::A list

> My name is Karun. I am trying to implement the CGI-Application-Dispatch-2.12 module which you developed. I downloaded and installed the module. In my application I am subclassing the dispatch_args  subroutine. When I run the URL I get a page not found error (404). I am using Apache server and mod_perl 2.0. My URL looks something like the following:
> 
> http://example.net:4042/WebApp/WebService/mode_get_page
> 
> For some reason it's failing in the table code. The following is the table code:
> 
> sub dispatch_args {
> 	my $self  = shift;
> 	my $DEBUG = true;
> 	my ( $self1, $new_args ) = @_;
> 	
> 	return {
>         	prefix  		=> 'WebApp',
>              table   		=> [
>                 '/WebService'       => { app => 'WebService', rm => 'mode_get_page' },
> 	           ],
> 	        #error_document  => '"Oops..."',
> 	        #default 		=> 'Test.html',
> 	        $DEBUG			=> 'true',
>         };
> 	
> }

I'll need a little more info than that. Are you using Apache? mod_perl?
mod_rewrite? If so, how are they configured for this location. Also, what C::A
module are you trying to dispatch to?

Also, I think you might be confused about what some of those values should be.
The 'prefix' isn't the URL prefix, it's the module name prefix. C::A::Dispatch
dispatches to C::A based modules. Also the url's are assumed to be all
lowercase. Look at the translate_module_name() name if you want to change this.
Looking at the URL you have and the, the prefix and the table your url will map
to a class named WebApp::Webservice. Does that module exist?

Also you seem to be a little confused about that $DEBUG there. For one, "true"
is can't exist without quotes (like you have in "my $DEBUG = true;" Perl doesn't
have true/false literals like that. Use 1 or 0. And then in your hash that you
return you have "$DEBUG => 'true'", that will not do what you think it will. Try
'debug => 1'.

-- 
Michael Peters
Developer
Plus Three, LP

From petr.vojkovsky at centrum.cz  Fri Feb  1 10:41:25 2008
From: petr.vojkovsky at centrum.cz (petr.vojkovsky@centrum.cz)
Date: Fri Feb  1 11:43:27 2008
Subject: [cgiapp] How to send pdf file?
Message-ID: <200802011641.28104@centrum.cz>

Hi,
I want send to browser pdf file (it exist):
I try do it in this rm:

use MIME::Base64;
...
--------------------------------
      my $self = shift;
	my $q = $self->query();
	my $session = undef();
	my $message = '';
	my $output = '';
	my $buf;
	my $files_location = 'PATH TO DIR'; 
	my $filename = 'exam1.pdf';
	open(FILE, "<$files_location/exam1.pdf") or die "$!";
	#binmode FILE;
	my @fs = stat(FILE);
	#my $file_size = $theFileStat->size;
	#my $file_size = $fs[7];
	while (read(FILE, $buf, 60*57)) {
		$output = $output . encode_base64($buf);
	}
	close (FILE); 
	$self->header_props(
		-type    => "application/pdf",
        	-attachment    => $filename,
		-Content_Length     => length($output),
        	-Content_Transfer_Encoding  => "base64",
    );
	$self->header_type('header');
	return $output;
---------------------------

Browser shows "Save as" window, but xpdf can't dislpay it. Why the browser automatically decode_base64 this file?
How to send binary file (*.pdf, *.jpg, ...) without Base64 encoding?


Thank you for advice.
Best regards,
Petr  

From mpeters at plusthree.com  Fri Feb  1 11:50:14 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Fri Feb  1 11:52:13 2008
Subject: [cgiapp] How to send pdf file?
In-Reply-To: <200802011641.28104@centrum.cz>
References: <200802011641.28104@centrum.cz>
Message-ID: <47A34DC6.2010309@plusthree.com>

petr.vojkovsky@centrum.cz wrote:
> Hi,
> I want send to browser pdf file (it exist):

If it already exists, it's much easier than that. Basically you just tell the
browser where to find the file and what type it is:

sub send_pdf {
  my $self = shift;
  $self->header_type('none'); # let's you set your own headers
  $self->header_props(
    -content-type         => 'application/pdf',
    -content-disposition' => 'inline; filename=myfile.pdf'
  );

  return 'Download myfile.pdf';
}

Or something like that. It's kind of tricky when you need to deal with caching,
SSL and IE - http://support.microsoft.com/kb/316431, but if you don't then it's
pretty easy.

-- 
Michael Peters
Developer
Plus Three, LP

From petr.vojkovsky at centrum.cz  Sun Feb  3 05:14:18 2008
From: petr.vojkovsky at centrum.cz (petr.vojkovsky@centrum.cz)
Date: Sun Feb  3 05:53:18 2008
Subject: [cgiapp] How to send pdf file?
Message-ID: <200802031114.29209@centrum.cz>

Hi Michael,
thank you for your answer.
MIME headers are correct, but I still don't know how to send binary output through CGI::Application.
On "classic" way it is easy:
open(FILE, "<test.pdf");  
@fileholder = <FILE>;  
close (FILE);  

print "Content-Type: application/pdf\n";  
print "Content-Disposition: attachment;filename=test.pdf\n\n";
print @fileholder;


How to do it through CGI::Application?

Petr

petr.vojkovsky@centrum.cz wrote:
> Hi,
> I want send to browser pdf file (it exist):

mpeters@plusthree.com wrote:
>If it already exists, it's much easier than that. Basically you just tell the
>browser where to find the file and what type it is:

>sub send_pdf {
>my $self = shift;
>$self->header_type('none'); # let's you set your own headers
>$self->header_props(
>-content-type => 'application/pdf',
>-content-disposition' => 'inline; filename=myfile.pdf'
>);
>
>return 'Download myfile.pdf';
>}

>Or something like that. It's kind of tricky when you need to deal with caching,
>SSL and IE - http://support.microsoft.com/kb/316431, but if you don't then it's
>pretty easy.

>-- 
>Michael Peters
>Developer
>Plus Three, LP

From jesse at erlbaum.net  Sun Feb  3 08:34:00 2008
From: jesse at erlbaum.net (Jesse Erlbaum)
Date: Sun Feb  3 08:49:34 2008
Subject: [cgiapp] How to send pdf file?
In-Reply-To: <200802031114.29209@centrum.cz>
References: <200802031114.29209@centrum.cz>
Message-ID: <F3690AC81E5390499D4723777E499F990486E8AB@34093-EVS1C1.exchange.rackspace.com>

Hi Petr --

> MIME headers are correct, but I still don't know how to send binary
> output through CGI::Application.
> On "classic" way it is easy:
> open(FILE, "<test.pdf");
> @fileholder = <FILE>;
> close (FILE);
> 
> print "Content-Type: application/pdf\n";
> print "Content-Disposition: attachment;filename=test.pdf\n\n";
> print @fileholder;
> 
> 
> How to do it through CGI::Application?


It's basically the same w/ CGI::Application, with two exceptions:

  1. You don't return the headers.  You set them.
  2. You don't print -- you return your data.


  sub send_pdf {
    my $self = shift;

    $self->header_props( -type => "application/pdf",
                         -"Content-Disposition"=>"attachment;filename=test.pdf"
                       );

    open(FILE, "<test.pdf");
    @fileholder = <FILE>;
    close (FILE);

    return join("", @fileholder);
  }


TTYL,

-Jesse-

?
Jesse Erlbaum
The Erlbaum Group, LLC
817 Broadway, 10th floor
New York, NY 10003
212-684-6161 (office)
917-647-3059 (mobile)
212-684-6226 (fax)
jesse@erlbaum.net



From hartzell at alerce.com  Sun Feb  3 12:48:28 2008
From: hartzell at alerce.com (George Hartzell)
Date: Sun Feb  3 12:48:32 2008
Subject: [cgiapp] How to send pdf file?
In-Reply-To: <200802031114.29209@centrum.cz>
References: <200802031114.29209@centrum.cz>
Message-ID: <18341.65132.683395.629924@almost.alerce.com>


There's also Jason Purdy's CGI::Application::Plugin::Stream, which
reads and write the file in chunks to avoid slurping it all into
memory at once.

  http://search.cpan.org/dist/CGI-Application-Plugin-Stream/lib/CGI/Application/Plugin/Stream.pm

g.

From pagaltzis at gmx.de  Sun Feb  3 14:17:30 2008
From: pagaltzis at gmx.de (Aristotle Pagaltzis)
Date: Sun Feb  3 14:17:34 2008
Subject: [cgiapp] Re: How to send pdf file?
In-Reply-To: <F3690AC81E5390499D4723777E499F990486E8AB@34093-EVS1C1.exchange.rackspace.com>
	<200802031114.29209@centrum.cz>
References: <200802031114.29209@centrum.cz>
	<F3690AC81E5390499D4723777E499F990486E8AB@34093-EVS1C1.exchange.rackspace.com>
	<47A34DC6.2010309@plusthree.com> <200802031114.29209@centrum.cz>
Message-ID: <20080203191730.GG25553@klangraum>

* petr.vojkovsky@centrum.cz <petr.vojkovsky@centrum.cz> [2008-02-03 11:55]:
> @fileholder = <FILE>;  
> print @fileholder;

* Jesse Erlbaum <jesse@erlbaum.net> [2008-02-03 14:50]:
>    @fileholder = <FILE>;
>    return join("", @fileholder);

Note that this is a really bad way to slurp a whole file. In the
worst case (2nd example) it will consume over thrice the size of
the file in memory.

In general, if you do slurp an entire file, you should do it
using `read`:

    read *FILE, $fileholder, -s *FILE;

But if you do that and then `return $fileholder`, you?ll still
get double the size of the file in memory consumption, because
Perl makes a copy of the scalar to return it.

The right approach in such cases is either passing around a file
handle (so the output can be streamed directly) or a reference
(but then the code which outputs it must still be written
carefully to avoid making a copy).

In case of a CGI::App app, the answer is to pass a file handle,
which is done using CGI::Application::Plugin::Stream. That will
also conveniently take care of setting all the requisite headers.

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.org/>
From lhernsen1015 at wowway.com  Sun Feb  3 19:02:32 2008
From: lhernsen1015 at wowway.com (Lou Hernsen)
Date: Sun Feb  3 19:07:01 2008
Subject: [cgiapp] How to send pdf file?
References: <200802031114.29209@centrum.cz>
Message-ID: <002c01c866c1$43330ec0$6401a8c0@lousmaster>

I klnow how to send an email with text.
How to I send an email with HTML in it?
Is there a special header or command or what?
Lou


----- Original Message ----- 
From: <petr.vojkovsky@centrum.cz>
To: <cgiapp@lists.erlbaum.net>
Sent: Sunday, February 03, 2008 5:14 AM
Subject: Re:Re: [cgiapp] How to send pdf file?


> Hi Michael,
> thank you for your answer.
> MIME headers are correct, but I still don't know how to send binary output
through CGI::Application.
> On "classic" way it is easy:
> open(FILE, "<test.pdf");
> @fileholder = <FILE>;
> close (FILE);
>
> print "Content-Type: application/pdf\n";
> print "Content-Disposition: attachment;filename=test.pdf\n\n";
> print @fileholder;
>
>
> How to do it through CGI::Application?
>
> Petr
>
> petr.vojkovsky@centrum.cz wrote:
> > Hi,
> > I want send to browser pdf file (it exist):
>
> mpeters@plusthree.com wrote:
> >If it already exists, it's much easier than that. Basically you just tell
the
> >browser where to find the file and what type it is:
>
> >sub send_pdf {
> >my $self = shift;
> >$self->header_type('none'); # let's you set your own headers
> >$self->header_props(
> >-content-type => 'application/pdf',
> >-content-disposition' => 'inline; filename=myfile.pdf'
> >);
> >
> >return 'Download myfile.pdf';
> >}
>
> >Or something like that. It's kind of tricky when you need to deal with
caching,
> >SSL and IE - http://support.microsoft.com/kb/316431, but if you don't
then it's
> >pretty easy.
>
> >-- 
> >Michael Peters
> >Developer
> >Plus Three, LP
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.16/1250 - Release Date: 1/29/08
10:20 PM
>
>

From mpeters at plusthree.com  Mon Feb  4 08:22:53 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Mon Feb  4 08:24:52 2008
Subject: [cgiapp] How to send pdf file?
In-Reply-To: <002c01c866c1$43330ec0$6401a8c0@lousmaster>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>
Message-ID: <47A711AD.3070106@plusthree.com>

Lou Hernsen wrote:
> I klnow how to send an email with text.
> How to I send an email with HTML in it?
> Is there a special header or command or what?

Wow, can you say completely unrelated to this topic :) Next time, try starting a
new thread. Not only will it not confuse people, but several people are probably
 already tuned out to the PDF conversation. So you're also missing out on an
audience.

Their called MIME emails. Do a search CPAN. I've used MIME::Lite with some
success, but it's not really "lite". I think Email::MIME is one of the preferred
modules now.

-- 
Michael Peters
Developer
Plus Three, LP

From lhernsen1015 at wowway.com  Mon Feb  4 10:01:16 2008
From: lhernsen1015 at wowway.com (Lou Hernsen)
Date: Mon Feb  4 10:04:35 2008
Subject: [cgiapp] NOT related to >>> How to send pdf file?
References: <200802031114.29209@centrum.cz><002c01c866c1$43330ec0$6401a8c0@lousmaster>
	<47A711AD.3070106@plusthree.com>
Message-ID: <001c01c8673e$d233c2e0$6401a8c0@lousmaster>

Oh... sorrry.. I forgot to change the subject line.. by bad....
thanks for the help anyways...
Lou

----- Original Message ----- 
From: "Michael Peters" <mpeters@plusthree.com>
To: "CGI Application" <cgiapp@lists.erlbaum.net>
Sent: Monday, February 04, 2008 8:22 AM
Subject: Re: [cgiapp] How to send pdf file?


> Lou Hernsen wrote:
> > I klnow how to send an email with text.
> > How to I send an email with HTML in it?
> > Is there a special header or command or what?
>
> Wow, can you say completely unrelated to this topic :) Next time, try
starting a
> new thread. Not only will it not confuse people, but several people are
probably
>  already tuned out to the PDF conversation. So you're also missing out on
an
> audience.
>
> Their called MIME emails. Do a search CPAN. I've used MIME::Lite with some
> success, but it's not really "lite". I think Email::MIME is one of the
preferred
> modules now.
>
> -- 
> Michael Peters
> Developer
> Plus Three, LP
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.16/1250 - Release Date: 1/29/08
10:20 PM
>
>

From mark at rawcane.net  Tue Feb  5 05:44:19 2008
From: mark at rawcane.net (Mark Knoop)
Date: Tue Feb  5 05:44:23 2008
Subject: [cgiapp] Persistence
References: <200802031114.29209@centrum.cz><002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
Message-ID: <010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>

Hi

I'm new to CGI::Application.

I like the way it makes me organize the script but I guess I could do it in 
this way without CGI:Application so I just want to be sure I fully 
understand the benefits.

Given that I am not running it under mod_perl at this stage is each instance 
request a completely seperate event or does CGI::Application somehow keep 
track of something between one user's calls to the same instance?

If so how?

If not then does CGI::Application offer any other benefits than helping one 
to organize ones code better?

I have read through lots of docs but I seem to be missing this key point... 
if there is a doc specifically related to this that would be a huge help.

Cheers
Mark




From mark at rawcane.net  Tue Feb  5 06:59:19 2008
From: mark at rawcane.net (Mark Knoop)
Date: Tue Feb  5 07:00:43 2008
Subject: [cgiapp] Persistence
References: <200802031114.29209@centrum.cz><002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com><001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
Message-ID: <014701c867ee$8a8c0a50$06fe000a@gboffice.gorillabox.net>

> Hi
>
> I'm new to CGI::Application.
>
> I like the way it makes me organize the script but I guess I could do it 
> in this way without CGI:Application so I just want to be sure I fully 
> understand the benefits.
>
> Given that I am not running it under mod_perl at this stage is each 
> instance request a completely seperate event or does CGI::Application 
> somehow keep track of something between one user's calls to the same 
> instance?
>
> If so how?
>
> If not then does CGI::Application offer any other benefits than helping 
> one to organize ones code better?
>
> I have read through lots of docs but I seem to be missing this key 
> point... if there is a doc specifically related to this that would be a 
> huge help.
>
> Cheers
> Mark
>
>
>
Ok... have made some progress. It seems I can use the 
CGI::Application::Plugin::Session  for the persistence side of things. But 
still feel like I am missing a trick.... will persevere and see if things 
become clearer. 

From ceeshek at gmail.com  Tue Feb  5 08:18:39 2008
From: ceeshek at gmail.com (Cees Hek)
Date: Tue Feb  5 08:18:43 2008
Subject: [cgiapp] Persistence
In-Reply-To: <014701c867ee$8a8c0a50$06fe000a@gboffice.gorillabox.net>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>
	<47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<014701c867ee$8a8c0a50$06fe000a@gboffice.gorillabox.net>
Message-ID: <fd8e28ef0802050518u6ba2edaahd4eb4387db07c74@mail.gmail.com>

On Feb 5, 2008 10:59 PM, Mark Knoop <mark@rawcane.net> wrote:
> > Hi
> >
> > I'm new to CGI::Application.

Welcome

> > I like the way it makes me organize the script but I guess I could do it
> > in this way without CGI:Application so I just want to be sure I fully
> > understand the benefits.
> >
> > Given that I am not running it under mod_perl at this stage is each
> > instance request a completely seperate event or does CGI::Application
> > somehow keep track of something between one user's calls to the same
> > instance?

No, CGI::Application by itself does not offer any persistance.  Each
request will create a new CGI::Application object.  You can use
mod_perl or FastCGI to make the code persistent, but it will still
create a new CGI::Application object on each request.

> > If not then does CGI::Application offer any other benefits than helping
> > one to organize ones code better?

If you look at the source code for CGI::Application you will see that
it is not very big and not very complex.  So yes you are correct in
thinking that you can probably structure your code that way without
using CGI::Application itself.

The benefit in using it is that you are using a module that has been
tried and tested over many years by thousands of people.  These people
all structure their apps in a very similar way (ie the
CGI::Application way), which means you can benefit from several thing:

Code re-use
- many people have spent time building lots of extensions to
CGI::Application that make life for a web developer much easier.  By
using CGI::Application as your base you can benefit from all this work
(search CPAN for CGI::Application::Plugin to see what is publicly
available).

Lower your Technical Debt
- Building your own application code structure and rebuilding your own
version of all the plugins that are available means you have to
maintain all that extra code.  And the person that takes over your
project in the future has to maintain and understand what you have
built.  Using well supported modules and best practices lowers your
technical debt for the future.  It also gives future maintainers a
starting place to look for help and documentation.

Help from your peers
- this mailing list has many people that may be able to help you if
you run into problems, but only if you use CGI::Application.  Building
it all yourself means you are less likely to find someone that can (or
is willing to) help you.


> Ok... have made some progress. It seems I can use the
> CGI::Application::Plugin::Session  for the persistence side of things. But
> still feel like I am missing a trick.... will persevere and see if things
> become clearer.

So it looks like you have already found some of the plugins :)  The
Session plugin will allow you to maintain state variables across
requests.  So if all you want to do is store some info for a user
between requests (like an authentication token, or maybe their
language preference, etc...) then the Session plugin will definately
do that for you.

If you still feel you are missing something, then explain to us what
you are trying to do, and what you are expecting an application
framework like CGI::Application to do for you.

Cheers,

Cees Hek
From mark at rawcane.net  Tue Feb  5 08:29:55 2008
From: mark at rawcane.net (Mark Knoop)
Date: Tue Feb  5 08:30:01 2008
Subject: [cgiapp] Persistence
References: <200802031114.29209@centrum.cz><002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com><001c01c8673e$d233c2e0$6401a8c0@lousmaster><010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net><014701c867ee$8a8c0a50$06fe000a@gboffice.gorillabox.net>
	<fd8e28ef0802050518u6ba2edaahd4eb4387db07c74@mail.gmail.com>
Message-ID: <01ac01c867fb$32a31560$06fe000a@gboffice.gorillabox.net>


> On Feb 5, 2008 10:59 PM, Mark Knoop <mark@rawcane.net> wrote:
>> > Hi
>> >
>> > I'm new to CGI::Application.
>
> Welcome
>
>> > I like the way it makes me organize the script but I guess I could do 
>> > it
>> > in this way without CGI:Application so I just want to be sure I fully
>> > understand the benefits.
>> >
>> > Given that I am not running it under mod_perl at this stage is each
>> > instance request a completely seperate event or does CGI::Application
>> > somehow keep track of something between one user's calls to the same
>> > instance?
>
> No, CGI::Application by itself does not offer any persistance.  Each
> request will create a new CGI::Application object.  You can use
> mod_perl or FastCGI to make the code persistent, but it will still
> create a new CGI::Application object on each request.
>
>> > If not then does CGI::Application offer any other benefits than helping
>> > one to organize ones code better?
>
> If you look at the source code for CGI::Application you will see that
> it is not very big and not very complex.  So yes you are correct in
> thinking that you can probably structure your code that way without
> using CGI::Application itself.
>
> The benefit in using it is that you are using a module that has been
> tried and tested over many years by thousands of people.  These people
> all structure their apps in a very similar way (ie the
> CGI::Application way), which means you can benefit from several thing:
>
> Code re-use
> - many people have spent time building lots of extensions to
> CGI::Application that make life for a web developer much easier.  By
> using CGI::Application as your base you can benefit from all this work
> (search CPAN for CGI::Application::Plugin to see what is publicly
> available).
>
> Lower your Technical Debt
> - Building your own application code structure and rebuilding your own
> version of all the plugins that are available means you have to
> maintain all that extra code.  And the person that takes over your
> project in the future has to maintain and understand what you have
> built.  Using well supported modules and best practices lowers your
> technical debt for the future.  It also gives future maintainers a
> starting place to look for help and documentation.
>
> Help from your peers
> - this mailing list has many people that may be able to help you if
> you run into problems, but only if you use CGI::Application.  Building
> it all yourself means you are less likely to find someone that can (or
> is willing to) help you.
>
>
>> Ok... have made some progress. It seems I can use the
>> CGI::Application::Plugin::Session  for the persistence side of things. 
>> But
>> still feel like I am missing a trick.... will persevere and see if things
>> become clearer.
>
> So it looks like you have already found some of the plugins :)  The
> Session plugin will allow you to maintain state variables across
> requests.  So if all you want to do is store some info for a user
> between requests (like an authentication token, or maybe their
> language preference, etc...) then the Session plugin will definately
> do that for you.
>
> If you still feel you are missing something, then explain to us what
> you are trying to do, and what you are expecting an application
> framework like CGI::Application to do for you.
>
> Cheers,
>
> Cees Hek
>
Thanks for the very thorough and helpful response. I will probably have many 
questions over the coming weeks but for now I suspect I need to try some 
things out and see how I go. It is already improving my (very messy) code 
just from the way it is forcing me to think about and structure my 
application but I guess will take some trial and error to fully appreciate 
the benefits and establish best practices. Will be back with some questions 
regarding specifics soon!

Cheers
Mark


From breadwild at gmail.com  Tue Feb  5 08:41:58 2008
From: breadwild at gmail.com (Brad Cathey)
Date: Tue Feb  5 08:42:01 2008
Subject: [cgiapp] Persistence
In-Reply-To: <010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>
	<47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
Message-ID: <9c83f0330802050541k21c82bfbm7e4c3fa13335218b@mail.gmail.com>

Bottomline, CGI::App does lots of the work for you. Life is easier. I
could not develop for the Web without it.

Brad

On Feb 5, 2008 4:44 AM, Mark Knoop <mark@rawcane.net> wrote:
> Hi
>
> I'm new to CGI::Application.
>
> I like the way it makes me organize the script but I guess I could do it in
> this way without CGI:Application so I just want to be sure I fully
> understand the benefits.
>
> Given that I am not running it under mod_perl at this stage is each instance
> request a completely seperate event or does CGI::Application somehow keep
> track of something between one user's calls to the same instance?
>
> If so how?
>
> If not then does CGI::Application offer any other benefits than helping one
> to organize ones code better?
>
> I have read through lots of docs but I seem to be missing this key point...
> if there is a doc specifically related to this that would be a huge help.
>
> Cheers
> Mark
>
>
>
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
From petr.vojkovsky at centrum.cz  Tue Feb  5 14:08:12 2008
From: petr.vojkovsky at centrum.cz (petr.vojkovsky@centrum.cz)
Date: Tue Feb  5 14:08:18 2008
Subject: [cgiapp] Re: How to send pdf file?
In-Reply-To: <20080203191730.GG25553@klangraum>
References: 200802031114.29209@centrum.cz>
	<F3690AC81E5390499D4723777E499F990486E8AB@34093-EVS1C1.exchange.rackspace.com>
	<20080203191730.GG25553@klangraum>
Message-ID: <200802052008.13631@centrum.cz>

Thank you very much, guys.
It works!

Best regards,
Petr
______________________________________________________________
> Od: pagaltzis@gmx.de
> Komu: cgiapp@lists.erlbaum.net
> Datum: 03.02.2008 20:26
> P?edm?t: [cgiapp] Re: How to send pdf file?
>
>* petr.vojkovsky@centrum.cz <petr.vojkovsky@centrum.cz> [2008-02-03
11:55]:
>> @fileholder = <FILE>;  
>> print @fileholder;
>
>* Jesse Erlbaum <jesse@erlbaum.net> [2008-02-03 14:50]:
>>    @fileholder = <FILE>;
>>    return join("", @fileholder);
>
>Note that this is a really bad way to slurp a whole file. In the
>worst case (2nd example) it will consume over thrice the size of
>the file in memory.
>
>In general, if you do slurp an entire file, you should do it
>using `read`:
>
>    read *FILE, $fileholder, -s *FILE;
>
>But if you do that and then `return $fileholder`, you?ll still
>get double the size of the file in memory consumption, because
>Perl makes a copy of the scalar to return it.
>
>The right approach in such cases is either passing around a file
>handle (so the output can be streamed directly) or a reference
>(but then the code which outputs it must still be written
>carefully to avoid making a copy).
>
>In case of a CGI::App app, the answer is to pass a file handle,
>which is done using CGI::Application::Plugin::Stream. That will
>also conveniently take care of setting all the requisite headers.
>
>-- 
>*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined
wantarray]/e;$1}
>&Just->another->Perl->hack;
>#Aristotle Pagaltzis // <http://plasmasturm.org/>
>
>#####  CGI::Application community mailing list  ################
>##                                                            ##
>##  To unsubscribe, or change your message delivery options,  ##
>##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
>##                                                            ##
>##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
>##  Wiki:          http://cgiapp.erlbaum.net/                 ##
>##                                                            ##
>################################################################
>
>

From ron at savage.net.au  Tue Feb  5 16:18:02 2008
From: ron at savage.net.au (Ron Savage)
Date: Tue Feb  5 16:17:14 2008
Subject: [cgiapp] Persistence
In-Reply-To: <010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
Message-ID: <1202246282.27200.94.camel@zoe.savage.net.au>

On Tue, 2008-02-05 at 10:44 +0000, Mark Knoop wrote:

Hi Mark

> I have read through lots of docs but I seem to be missing this key point... 
> if there is a doc specifically related to this that would be a huge help.

On top of the other responses, I'd add:
Your application must keep track of a 'session'. The main ways to do
that are:

o Add a hidden field to each CGI form, in which you send out to the
client the id of their session, so that when the use submits the form
you get back their id. This is my preferred alternative

o Add the session id to a cookie sent from your code, which you get back
later from the client. This is a commonly-used method

o Add the session id to the URL. This method has the most problems, and
is not recommended.

The session id is generated by CGI::Session.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From mark at rawcane.net  Wed Feb  6 03:16:33 2008
From: mark at rawcane.net (Mark Knoop)
Date: Wed Feb  6 03:16:39 2008
Subject: [cgiapp] Persistence
References: <200802031114.29209@centrum.cz><002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com><001c01c8673e$d233c2e0$6401a8c0@lousmaster><010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
Message-ID: <039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>

 >
> On top of the other responses, I'd add:
> Your application must keep track of a 'session'. The main ways to do
> that are:
>
> o Add a hidden field to each CGI form, in which you send out to the
> client the id of their session, so that when the use submits the form
> you get back their id. This is my preferred alternative
>
> o Add the session id to a cookie sent from your code, which you get back
> later from the client. This is a commonly-used method
>
> o Add the session id to the URL. This method has the most problems, and
> is not recommended.
>
> The session id is generated by CGI::Session.

Surely 1 and 3 are the same (except possibly you are talking about a post vs 
get)?

What are the problems with the last option? This is the way I have to 
approach it as I can't rely on the browsers I am dealing with to allow 
cookies. It's worked fine up to now... 

From mark at rawcane.net  Wed Feb  6 07:16:26 2008
From: mark at rawcane.net (Mark Knoop)
Date: Wed Feb  6 07:16:44 2008
Subject: [cgiapp] Changing CGI::Session name within a CGI::Application
Message-ID: <00bd01c868ba$18a26200$06fe000a@gboffice.gorillabox.net>

Hi

I am trying to use the CGI::Application::Plugin::Session but I am getting a 
bit confused with what objects are what.

In my cgiapp_init method I have the following:

CGI::Session->name('lsid');
$self->session_config(
       CGI_SESSION_OPTIONS => [ "driver:File", $self->query, { 
Dir=>$session_path  } ],
       DEFAULT_EXPIRY      => '+5m',
       SEND_COOKIE         => 0,
);

Then in my cgiapp_prerun I use

my $session = $self->session;

unless ( $self->session->param('rsid') ) {
    $self->session->param('rsid', 'SOME_VALUE');
    # some code to change prerun mode to redirect to external site
}

and then use $self->session->id as the value to lsid param in a callback url 
which I pass to an external app that I then redirect to
so that when they redirect back with the lsid param in the query string it 
will use that as the session id.

For some reason it is not picking up the session data correctly ie it is 
acting as if rsid in the session data does not exist and redoing the 
redirect though I can't tell whether it is because it is not automatically 
using the lsid param (which is definitely there) or whether it is not 
creating the session successfully in the first place.

It is going to be tricky to create a working example because of the 
redirects but is there anything that I am obviously approaching in the wrong 
way or any obvious errors?

Is there a way I test to see whether $self->session is creating a new 
session or picking up an existing one or not working at all?

Cheers
Mark
 

From mark at rawcane.net  Wed Feb  6 09:19:36 2008
From: mark at rawcane.net (Mark Knoop)
Date: Wed Feb  6 09:19:51 2008
Subject: [cgiapp] Changing CGI::Session name within a CGI::Application
References: <00bd01c868ba$18a26200$06fe000a@gboffice.gorillabox.net>
Message-ID: <014901c868cb$4dd3b8f0$06fe000a@gboffice.gorillabox.net>


> Hi
>
> I am trying to use the CGI::Application::Plugin::Session but I am getting 
> a bit confused with what objects are what.
> ...

Ok. I have made some progress in pinnign this down and it seems I have a 
problem with the session object.

This code recreates the scenario.

package GSystem::Test;
use base 'CGI::Application';
use strict;

use CGI::Carp qw(fatalsToBrowser);
use CGI::Application::Plugin::Session;

sub cgiapp_init {

    my $self = shift;
  my $session_path;

 CGI::Session->name('lsid');
    $self->session_config(
       CGI_SESSION_OPTIONS => [ "driver:File", $self->query, { 
Dir=>'D:\sessions\\' } ], # running on windows/IIS
       DEFAULT_EXPIRY      => '+5m',
       SEND_COOKIE         => 0,
    );

}

sub setup {

 my $self = shift;

    $self->start_mode('no_lsid');

    $self->run_modes(
  'got_lsid' => 'got_lsid',
  'no_lsid' => 'no_lsid'
    );


}

sub cgiapp_prerun {

 my $self = shift;

 my $session = $self->session;

    if ($self->query->param('lsid') ) {
  $self->prerun_mode('got_lsid');
 } else {
  $self->session->param('rsid', 'SOME_VALUE');
  $self->prerun_mode('no_lsid');
    }
}

sub got_lsid {

 my $self = shift;

 my $lsid = $self->session->id;
 my $rsid = $self->session->param('rsid');

 my $output = <<EOF;

 <html><body>Got lsid $lsid - rsid is $rsid</body></html>

EOF

 return $output;

}

sub no_lsid {

 my $self = shift;

 my $lsid = $self->session->id;

 my $output = <<EOF;

 <html><body>New lsid is $lsid - <a href = 
"http://my.url.com/test.pl?lsid=$lsid">Link</a></body></html>

EOF

 return $output;
}

1;

If I call this with no parameters it returns a link with the new session id 
as a value to lsid. If I click on this then it runs the got_lsid run mode 
but has not successfully retrieved the rsid value from the session data and 
has created a new session id.

Any ideas on how to pin this down?  I'm sure I am doing something dumb...

Cheers
Mark 

From mark at rawcane.net  Wed Feb  6 09:56:14 2008
From: mark at rawcane.net (Mark Knoop)
Date: Wed Feb  6 09:56:28 2008
Subject: [cgiapp] Changing CGI::Session name within a CGI::Application
References: <00bd01c868ba$18a26200$06fe000a@gboffice.gorillabox.net>
	<014901c868cb$4dd3b8f0$06fe000a@gboffice.gorillabox.net>
Message-ID: <017201c868d0$6beb2d00$06fe000a@gboffice.gorillabox.net>


>
>> Hi
>>
>> I am trying to use the CGI::Application::Plugin::Session but I am getting 
>> a bit confused with what objects are what.
>> ...
>
> Ok. I have made some progress in pinnign this down and it seems I have a 
> problem with the session object.
>
> This code recreates the scenario.
>
> package GSystem::Test;
> use base 'CGI::Application';
> use strict;
>
> use CGI::Carp qw(fatalsToBrowser);
> use CGI::Application::Plugin::Session;
>
> sub cgiapp_init {
>
>    my $self = shift;
>  my $session_path;
>
> CGI::Session->name('lsid');
>    $self->session_config(
>       CGI_SESSION_OPTIONS => [ "driver:File", $self->query, { 
> Dir=>'D:\sessions\\' } ], # running on windows/IIS
>       DEFAULT_EXPIRY      => '+5m',
>       SEND_COOKIE         => 0,
>    );
>
> }
>
> sub setup {
>
> my $self = shift;
>
>    $self->start_mode('no_lsid');
>
>    $self->run_modes(
>  'got_lsid' => 'got_lsid',
>  'no_lsid' => 'no_lsid'
>    );
>
>
> }
>
> sub cgiapp_prerun {
>
> my $self = shift;
>
> my $session = $self->session;
>
>    if ($self->query->param('lsid') ) {
>  $self->prerun_mode('got_lsid');
> } else {
>  $self->session->param('rsid', 'SOME_VALUE');
>  $self->prerun_mode('no_lsid');
>    }
> }
>
> sub got_lsid {
>
> my $self = shift;
>
> my $lsid = $self->session->id;
> my $rsid = $self->session->param('rsid');
>
> my $output = <<EOF;
>
> <html><body>Got lsid $lsid - rsid is $rsid</body></html>
>
> EOF
>
> return $output;
>
> }
>
> sub no_lsid {
>
> my $self = shift;
>
> my $lsid = $self->session->id;
>
> my $output = <<EOF;
>
> <html><body>New lsid is $lsid - <a href = 
> "http://my.url.com/test.pl?lsid=$lsid">Link</a></body></html>
>
> EOF
>
> return $output;
> }
>
> 1;
>
> If I call this with no parameters it returns a link with the new session 
> id as a value to lsid. If I click on this then it runs the got_lsid run 
> mode but has not successfully retrieved the rsid value from the session 
> data and has created a new session id.
>

I just tried recreating this using CGI::Session directly and it worked as I 
had hoped, even with cookies disabled in my browser.

################################

use strict;
#use warnings;
use CGI qw/:standard/;
use CGI::Session;

my $cgi = new CGI;

CGI::Session->name('lsid');

my $session  = new CGI::Session("driver:File", $cgi, 
{Directory=>'D:\sessions\\'});
$session->expire('+5m');

my $lsid = $session->id;

my $rsid;

if ($cgi->param('lsid') ) {
 $rsid = $session->param('rsid');

 print $cgi->header;
 print <<EOF;
 <html><body>Got lsid $lsid - rsid is $rsid</body></html>
EOF
} else {
 $session->param('rsid','SOME_VALUE');
 print $cgi->header;
 print <<EOF;
 <html><body>New lsid is $lsid - <a href = 
"http://my.url.com/test_noca.pl?lsid=$lsid">Link</a></body></html>
EOF
}

exit;

##################

The notable difference is that I can see the session data files appearing in 
D:\sessions whereas they were not with my previous attempt. Any thoughts?

Mark


From mark at rawcane.net  Wed Feb  6 11:10:34 2008
From: mark at rawcane.net (Mark Knoop)
Date: Wed Feb  6 11:10:40 2008
Subject: [cgiapp] Changing CGI::Session name within a CGI::Application
Message-ID: <01f901c868da$ce067cb0$06fe000a@gboffice.gorillabox.net>

Aargh. Ignore all the above. For some insane reason I was using Dir instead 
of Directory in the session_config inside the CGI::Application version.

Still... was great opportunity to really get to grips with the module :)



From ron at savage.net.au  Wed Feb  6 16:47:25 2008
From: ron at savage.net.au (Ron Savage)
Date: Wed Feb  6 16:46:32 2008
Subject: [cgiapp] Persistence
In-Reply-To: <039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
Message-ID: <1202334445.27200.103.camel@zoe.savage.net.au>

On Wed, 2008-02-06 at 08:16 +0000, Mark Knoop wrote:

Hi Mark

>  >
> > On top of the other responses, I'd add:
> > Your application must keep track of a 'session'. The main ways to do
> > that are:
> >
> > o Add a hidden field to each CGI form, in which you send out to the
> > client the id of their session, so that when the use submits the form
> > you get back their id. This is my preferred alternative
> >
> > o Add the session id to a cookie sent from your code, which you get back
> > later from the client. This is a commonly-used method
> >
> > o Add the session id to the URL. This method has the most problems, and
> > is not recommended.
> >
> > The session id is generated by CGI::Session.
> 
> Surely 1 and 3 are the same (except possibly you are talking about a post vs 
> get)?

Not really.

> What are the problems with the last option? This is the way I have to 
> approach it as I can't rely on the browsers I am dealing with to allow 
> cookies. It's worked fine up to now... 

Google for XSS - Cross-site scripting attacks, as a starter.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From mpeters at plusthree.com  Wed Feb  6 16:47:17 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Wed Feb  6 16:49:21 2008
Subject: [cgiapp] Persistence
In-Reply-To: <1202334445.27200.103.camel@zoe.savage.net.au>
References: <200802031114.29209@centrum.cz>	<002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com>	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>	<1202246282.27200.94.camel@zoe.savage.net.au>	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
Message-ID: <47AA2AE5.4020208@plusthree.com>

Ron Savage wrote:

>>> o Add the session id to the URL. This method has the most problems, and
>>> is not recommended.
>>>
>>> The session id is generated by CGI::Session.
>> Surely 1 and 3 are the same (except possibly you are talking about a post vs 
>> get)?
> 
> Not really.
> 
>> What are the problems with the last option? This is the way I have to 
>> approach it as I can't rely on the browsers I am dealing with to allow 
>> cookies. It's worked fine up to now... 
> 
> Google for XSS - Cross-site scripting attacks, as a starter.

Maybe I'm being dense, but XSS is about letting user's embed HTML/JS into other
documents. So you need to protect against nefarious JS folks. How does putting
the session id in the URL cause XSS problems? XSS is all about *escaping* user
entered data when outputting it.

-- 
Michael Peters
Developer
Plus Three, LP

From azfuller at gmail.com  Wed Feb  6 17:11:18 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Wed Feb  6 17:11:20 2008
Subject: [cgiapp] Persistence
In-Reply-To: <1202334445.27200.103.camel@zoe.savage.net.au>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>
	<47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
Message-ID: <d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>

> > > o Add the session id to the URL. This method has the most problems, and
> > > is not recommended.
> >
> > What are the problems with the last option? ...
>
> Google for XSS - Cross-site scripting attacks, as a starter.

I thought the problem with putting the session ID in the URL is that
the user might copy/paste the URL to others. When they try to use it,
the app would have no way to know it's not the real user?

Maybe I've misunderstood the original question?

Mark
From mpeters at plusthree.com  Wed Feb  6 17:16:47 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Wed Feb  6 17:18:51 2008
Subject: [cgiapp] Persistence
In-Reply-To: <d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
References: <200802031114.29209@centrum.cz>	<002c01c866c1$43330ec0$6401a8c0@lousmaster>	<47A711AD.3070106@plusthree.com>	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>	<1202246282.27200.94.camel@zoe.savage.net.au>	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
Message-ID: <47AA31CF.6010608@plusthree.com>



Mark Fuller wrote:
>>>> o Add the session id to the URL. This method has the most problems, and
>>>> is not recommended.
>>> What are the problems with the last option? ...
>> Google for XSS - Cross-site scripting attacks, as a starter.
> 
> I thought the problem with putting the session ID in the URL is that
> the user might copy/paste the URL to others. When they try to use it,
> the app would have no way to know it's not the real user?

While that is a problem (it holds true with any user identifiable information
not just sessions. You need to especially watch what you put into emails since
they will get forwarded) it's not XSS.

XSS is Cross Site Scripting. So you need 2 domains (hence the cross-site) and it
involves Javascript (can also be ActionScript/Flash, VBScript, or any other
future client-side scripting language). Basically it's problem of people
embedding Javascript into a page that others will see. That Javascript can steal
sessions, etc from the user who sees it. It doesn't matter if the session id is
in the URL or a cookie, Javascript can see both.

This is why escaping any data that could potentially come from a user is so
important.

  <tmpl_var foo escape=html>
or
  [% foo | html %]

-- 
Michael Peters
Developer
Plus Three, LP

From fluffymike at googlemail.com  Wed Feb  6 17:51:10 2008
From: fluffymike at googlemail.com (Mike Tonks)
Date: Wed Feb  6 17:51:14 2008
Subject: [cgiapp] Multiple run modes
Message-ID: <727692630802061451v772b03dibca485821e077e5f@mail.gmail.com>

Hi,

I'm looking at CGI::Application prior to use, and one thing is unclear to me.

I'll outline a little senario to demonstrate the question:

I have a simple app with four run modes - list, view, edit & update

list does what it say on the tin - lists records in a data table

view ditto, displays a single record

edit displays a form to edit (or add) a record

update sends the posted data to the database


In my example, I would like the update run mode to then call the view
run mode, rather then simply display a rather useless 'update
complete' message.

Is there a good way to do this with CA?  I  suppose a simple option is
to simply have update() call view() and return the results, but I
wondered if there was a preferred solution to this?

Another thought that occurred from scanning the docs would be to put
the update function in prerun, but this seems wrong somehow.

Thanks for any assistance,

mike
From dan.horne at redbone.co.nz  Wed Feb  6 18:39:03 2008
From: dan.horne at redbone.co.nz (Dan Horne)
Date: Wed Feb  6 18:39:25 2008
Subject: [cgiapp] Persistence
In-Reply-To: <d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>
	<47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
Message-ID: <45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>

Mark Fuller said:

> I thought the problem with putting the session ID in the URL is that
> the user might copy/paste the URL to others. When they try to use it,
> the app would have no way to know it's not the real user?
>

Another problem is bookmarks. A user may bookmark a page, but when they
come back a couple of days later, the session has expired. They might also
email a link to others, and that link may not work for the same reason.

From dan.horne at redbone.co.nz  Wed Feb  6 18:43:26 2008
From: dan.horne at redbone.co.nz (Dan Horne)
Date: Wed Feb  6 18:43:29 2008
Subject: [cgiapp] Multiple run modes
In-Reply-To: <727692630802061451v772b03dibca485821e077e5f@mail.gmail.com>
References: <727692630802061451v772b03dibca485821e077e5f@mail.gmail.com>
Message-ID: <46471.210.54.245.44.1202341406.squirrel@mail.redbone.co.nz>

Mike Tonks said:
> Hi,
>
> I'm looking at CGI::Application prior to use, and one thing is unclear to
> me.
>
> I'll outline a little senario to demonstrate the question:
>
> I have a simple app with four run modes - list, view, edit & update
>
> list does what it say on the tin - lists records in a data table
>
> view ditto, displays a single record
>
> edit displays a form to edit (or add) a record
>
> update sends the posted data to the database
>
>
> In my example, I would like the update run mode to then call the view
> run mode, rather then simply display a rather useless 'update
> complete' message.
>
> Is there a good way to do this with CA?  I  suppose a simple option is
> to simply have update() call view() and return the results, but I
> wondered if there was a preferred solution to this?

Well you could simply call the view runmode after the update runmode has
run, but there are two recommended ways -
CGI::Application::Plugin::Forward and CGI::Application::Plugin::Redirect.
I prefer the latter, as a refresh of the browser doesn't resubmit the data
(which the first two methods would)
>
> Another thought that occurred from scanning the docs would be to put
> the update function in prerun, but this seems wrong somehow.
>
You probably want to avoid this - it's just getting messy

From dan.horne at redbone.co.nz  Wed Feb  6 18:48:24 2008
From: dan.horne at redbone.co.nz (Dan Horne)
Date: Wed Feb  6 18:49:14 2008
Subject: [cgiapp] Persistence
In-Reply-To: <45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>
	<47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
Message-ID: <48019.210.54.245.44.1202341704.squirrel@mail.redbone.co.nz>

Dan Horne said:
> Mark Fuller said:
>
>> I thought the problem with putting the session ID in the URL is that
>> the user might copy/paste the URL to others. When they try to use it,
>> the app would have no way to know it's not the real user?
>>
>
> Another problem is bookmarks. A user may bookmark a page, but when they
> come back a couple of days later, the session has expired. They might also
> email a link to others, and that link may not work for the same reason.
>
>
Oh and having the session in the URL may affect your caching algorithms,
which may or may not be a problem, depending on your app. If an e-commerce
app used page-based caching (say a product page as determined by the
request URL) then each session would have a unique URL, and hence would
get its own cache.

From barry.moore at genetics.utah.edu  Wed Feb  6 19:04:56 2008
From: barry.moore at genetics.utah.edu (Barry Moore)
Date: Wed Feb  6 19:09:00 2008
Subject: [cgiapp] Persistence
In-Reply-To: <47AA31CF.6010608@plusthree.com>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>	<47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<47AA31CF.6010608@plusthree.com>
Message-ID: <78A40BC4-66B7-4759-9C0C-F9F8BA478B88@genetics.utah.edu>

This is an interesting thread, and XSS is something that I haven't  
really understood.  Let me see if I'm understanding this correctly:

Basically one version of an XSS attack would be for me to enter  
javascript code into a form on your web page.  Then if you include my  
form submission in other web pages then my javascript could execute  
on any other users machine that subsequently loaded those tainted  
pages.  My JS code could do anything that they could do including  
contact your server on behalf of them and send data back to my  
server.  Is this correct?

Then the rational for you to html escape any input that comes from me  
and any other user is because that escaping would render the JS code  
in-operable.  Is that correct?

So then is is safe to assume that if the data from your form never  
gets sent back to other users (i.e. it only gets analyzed by your  
server - such as a search form) or if you check for JS code in some  
other way, then that would also prevent this form of XSS?

Barry

On Feb 6, 2008, at 3:16 PM, Michael Peters wrote:

>
>
> Mark Fuller wrote:
>>>>> o Add the session id to the URL. This method has the most  
>>>>> problems, and
>>>>> is not recommended.
>>>> What are the problems with the last option? ...
>>> Google for XSS - Cross-site scripting attacks, as a starter.
>>
>> I thought the problem with putting the session ID in the URL is that
>> the user might copy/paste the URL to others. When they try to use it,
>> the app would have no way to know it's not the real user?
>
> While that is a problem (it holds true with any user identifiable  
> information
> not just sessions. You need to especially watch what you put into  
> emails since
> they will get forwarded) it's not XSS.
>
> XSS is Cross Site Scripting. So you need 2 domains (hence the cross- 
> site) and it
> involves Javascript (can also be ActionScript/Flash, VBScript, or  
> any other
> future client-side scripting language). Basically it's problem of  
> people
> embedding Javascript into a page that others will see. That  
> Javascript can steal
> sessions, etc from the user who sees it. It doesn't matter if the  
> session id is
> in the URL or a cookie, Javascript can see both.
>
> This is why escaping any data that could potentially come from a  
> user is so
> important.
>
>   <tmpl_var foo escape=html>
> or
>   [% foo | html %]
>
> --
> Michael Peters
> Developer
> Plus Three, LP
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>

From barry.moore at genetics.utah.edu  Wed Feb  6 19:06:49 2008
From: barry.moore at genetics.utah.edu (Barry Moore)
Date: Wed Feb  6 19:09:00 2008
Subject: [cgiapp] XSS
References: <78A40BC4-66B7-4759-9C0C-F9F8BA478B88@genetics.utah.edu>
Message-ID: <06483281-05D5-4CFB-B4EF-B99B18BEF917@genetics.utah.edu>

Sorry for the second post.  I decided that this topic has diverged  
enough it should be a separate thread.  Reply to this one instead if  
you see it in time.

This is an interesting thread, and XSS is something that I haven't  
really understood.  Let me see if I'm understanding this correctly:

Basically one version of an XSS attack would be for me to enter  
javascript code into a form on your web page.  Then if you include my  
form submission in other web pages then my javascript could execute  
on any other users machine that subsequently loaded those tainted  
pages.  My JS code could do anything that they could do including  
contact your server on behalf of them and send data back to my  
server.  Is this correct?

Then the rational for you to html escape any input that comes from me  
and any other user is because that escaping would render the JS code  
in-operable.  Is that correct?

So then is is safe to assume that if the data from your form never  
gets sent back to other users (i.e. it only gets analyzed by your  
server - such as a search form) or if you check for JS code in some  
other way, then that would also prevent this form of XSS?

Barry

On Feb 6, 2008, at 3:16 PM, Michael Peters wrote:

>
>
> Mark Fuller wrote:
>>>>> o Add the session id to the URL. This method has the most  
>>>>> problems, and
>>>>> is not recommended.
>>>> What are the problems with the last option? ...
>>> Google for XSS - Cross-site scripting attacks, as a starter.
>>
>> I thought the problem with putting the session ID in the URL is that
>> the user might copy/paste the URL to others. When they try to use it,
>> the app would have no way to know it's not the real user?
>
> While that is a problem (it holds true with any user identifiable  
> information
> not just sessions. You need to especially watch what you put into  
> emails since
> they will get forwarded) it's not XSS.
>
> XSS is Cross Site Scripting. So you need 2 domains (hence the cross- 
> site) and it
> involves Javascript (can also be ActionScript/Flash, VBScript, or  
> any other
> future client-side scripting language). Basically it's problem of  
> people
> embedding Javascript into a page that others will see. That  
> Javascript can steal
> sessions, etc from the user who sees it. It doesn't matter if the  
> session id is
> in the URL or a cookie, Javascript can see both.
>
> This is why escaping any data that could potentially come from a  
> user is so
> important.
>
>   <tmpl_var foo escape=html>
> or
>   [% foo | html %]
>
> --
> Michael Peters
> Developer
> Plus Three, LP
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>


From stephen.carville at gmail.com  Wed Feb  6 19:22:32 2008
From: stephen.carville at gmail.com (Stephen Carville)
Date: Wed Feb  6 19:23:20 2008
Subject: [cgiapp] Persistence
In-Reply-To: <45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>
	<47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
Message-ID: <2428c0380802061622u50ae1267kd17adfdac937e341@mail.gmail.com>

On Feb 6, 2008 3:39 PM, Dan Horne <dan.horne@redbone.co.nz> wrote:
> Mark Fuller said:
>
> > I thought the problem with putting the session ID in the URL is that
> > the user might copy/paste the URL to others. When they try to use it,
> > the app would have no way to know it's not the real user?
> >
>
> Another problem is bookmarks. A user may bookmark a page, but when they
> come back a couple of days later, the session has expired. They might also
> email a link to others, and that link may not work for the same reason.

Seems to me it makes more sense to embed the session ID or any other
tracking as hidden variables in a form and send it back as a POST.

-- 
Stephen Carville
From karen.cravens at gmail.com  Wed Feb  6 21:11:50 2008
From: karen.cravens at gmail.com (Karen)
Date: Wed Feb  6 21:11:51 2008
Subject: [cgiapp] Persistence
In-Reply-To: <45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>
	<47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
Message-ID: <7cc7c1ce0802061811x34f0a4aat95caabe8da262ca3@mail.gmail.com>

On 2/6/08, Dan Horne <dan.horne@redbone.co.nz> wrote:

> Another problem is bookmarks. A user may bookmark a page, but when they
> come back a couple of days later, the session has expired. They might also
> email a link to others, and that link may not work for the same reason.

If you want a poster child for this particular evilness, and how it
can be compounded: Joann.com (fabric/craft chain). You get bloggers
who post links (craftblogging is a big thing), with their session id,
and when you read and click, you get taken to a page that informs you
that the session has expired... and it dumps you to the joann.com home
page. If you're savvy editing the url, you can go back and edit it to
get there, but otherwise there is absolutely no way to tell where the
blogger meant you to go.

I think they've been trying to fix that lately. I am only guessing,
though, since the only symptom of change I've seen is that now if I go
directly to the joann.com homepage, I am sent to a page telling me my
session has expired, and I have to click a link to go back to the
homepage.  So apparently they're doing something with cookies now, but
it's not an improvement...
From ron at savage.net.au  Thu Feb  7 02:57:32 2008
From: ron at savage.net.au (Ron Savage)
Date: Thu Feb  7 02:56:41 2008
Subject: [cgiapp] Persistence
In-Reply-To: <47AA2AE5.4020208@plusthree.com>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<47AA2AE5.4020208@plusthree.com>
Message-ID: <1202371052.27200.107.camel@zoe.savage.net.au>

On Wed, 2008-02-06 at 16:47 -0500, Michael Peters wrote:

Hi Michael

> Maybe I'm being dense, but XSS is about letting user's embed HTML/JS into other

Maybe I'm raving again. I was hoping OP could use XSS as a search key to
save me thinking. Perhaps I should have tried the search myself :-(.
Everybody can go back to sleep now.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ron at savage.net.au  Thu Feb  7 03:00:23 2008
From: ron at savage.net.au (Ron Savage)
Date: Thu Feb  7 02:59:29 2008
Subject: [cgiapp] Persistence
In-Reply-To: <47AA31CF.6010608@plusthree.com>
References: <200802031114.29209@centrum.cz>
	<002c01c866c1$43330ec0$6401a8c0@lousmaster>
	<47A711AD.3070106@plusthree.com>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<47AA31CF.6010608@plusthree.com>
Message-ID: <1202371223.27200.111.camel@zoe.savage.net.au>

On Wed, 2008-02-06 at 17:16 -0500, Michael Peters wrote:

Hi Michael

> This is why escaping any data that could potentially come from a user is so
> important.

Not just escaping. OP should be warned that server code cannot just rely
on Javascript-base validation. Someone might disable Javascript and
sumbit something nasty. That means the validation should be duplicated
on the server too. And yes, that's a PITA.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From mark at rawcane.net  Thu Feb  7 03:57:46 2008
From: mark at rawcane.net (Mark Knoop)
Date: Thu Feb  7 03:57:53 2008
Subject: [cgiapp] Persistence
References: <200802031114.29209@centrum.cz><002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com><001c01c8673e$d233c2e0$6401a8c0@lousmaster><010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net><1202246282.27200.94.camel@zoe.savage.net.au><039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net><1202334445.27200.103.camel@zoe.savage.net.au><d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
Message-ID: <032f01c86967$827ff130$06fe000a@gboffice.gorillabox.net>


> Mark Fuller said:
>
>> I thought the problem with putting the session ID in the URL is that
>> the user might copy/paste the URL to others. When they try to use it,
>> the app would have no way to know it's not the real user?
>>
>
> Another problem is bookmarks. A user may bookmark a page, but when they
> come back a couple of days later, the session has expired. They might also
> email a link to others, and that link may not work for the same reason.
>
>
 I think for my purposes having a 5 minute expiry time is sufficient to 
preventing this kind of problem. If the session has expired it will renew 
the session data. I am only using sessions to avoid having to do remote 
calls for every request. I could also use the IP security feature and UA 
matching to lock it down further but is not critical.

Cheers
Mark


From david at sitesuite.com.au  Thu Feb  7 04:04:50 2008
From: david at sitesuite.com.au (David Baxter)
Date: Thu Feb  7 04:06:04 2008
Subject: [cgiapp] Multiple run modes
In-Reply-To: <727692630802061451v772b03dibca485821e077e5f@mail.gmail.com>
References: <727692630802061451v772b03dibca485821e077e5f@mail.gmail.com>
Message-ID: <47AAC9B2.9060907@sitesuite.com.au>

Hi Mike,

My preferred way is to simply call the view runmode after the update has 
completed. That way you can pass variable or parameters back to the view 
to prompt a message to be displayed.

e.g.

sub update {
    my $self = shift;
    # update the record
    ...
    # set a message to be displayed in the view runmode
    my $message = "The $id record was successfully updated.";
    return $self->view($message);
}

Regards,

David

Mike Tonks wrote:
> Hi,
>
> I'm looking at CGI::Application prior to use, and one thing is unclear to me.
>
> I'll outline a little senario to demonstrate the question:
>
> I have a simple app with four run modes - list, view, edit & update
>
> list does what it say on the tin - lists records in a data table
>
> view ditto, displays a single record
>
> edit displays a form to edit (or add) a record
>
> update sends the posted data to the database
>
>
> In my example, I would like the update run mode to then call the view
> run mode, rather then simply display a rather useless 'update
> complete' message.
>
> Is there a good way to do this with CA?  I  suppose a simple option is
> to simply have update() call view() and return the results, but I
> wondered if there was a preferred solution to this?
>
> Another thought that occurred from scanning the docs would be to put
> the update function in prerun, but this seems wrong somehow.
>
> Thanks for any assistance,
>
> mike
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
>
>
>   
From mark at rawcane.net  Thu Feb  7 05:34:25 2008
From: mark at rawcane.net (Mark Knoop)
Date: Thu Feb  7 05:34:32 2008
Subject: [cgiapp] params, params, params...
Message-ID: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>

Hi

I would be grateful if someone could offer me some guidance.

When I started thinking about reorganising my app with CGI::Application but 
before I knew much about it I thought it would be good to have a Globals 
object which I set up when the script is called which stores all the things 
I need - some query params and some other values which I calculate based on 
the query params and things like session ids etc rather than have loads of 
package variables. In practice I am not sure if this is an improvement 
although there are some individual get and set methods that require extra 
functionality so is quite nice to have these in my own class.

Also I see that CGI::Application has its own params - am I right in thinking 
these are completeley different to the query params? Is there any 
relationship between the two? Should I just be using these for 'global' 
values?

It also looks like I will be using the session plugin and the session object 
also has its own params, some of which I would set with the 
global/query/params that I am interested in.

So I have three lots of params as well as my own Globals class and I am not 
sure which the tidiest option is.

Can anyone suggest any best practices on which params to use where?

I want to make my variables easy to keep track of and keep the code as 
maintainable and readable as possible.

Regards
Mark 

From mpeters at plusthree.com  Fri Feb  8 10:24:16 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Fri Feb  8 10:26:24 2008
Subject: [cgiapp] Persistence
In-Reply-To: <2428c0380802061622u50ae1267kd17adfdac937e341@mail.gmail.com>
References: <200802031114.29209@centrum.cz>	<002c01c866c1$43330ec0$6401a8c0@lousmaster>	<47A711AD.3070106@plusthree.com>	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>	<1202246282.27200.94.camel@zoe.savage.net.au>	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>	<1202334445.27200.103.camel@zoe.savage.net.au>	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>	<45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
	<2428c0380802061622u50ae1267kd17adfdac937e341@mail.gmail.com>
Message-ID: <47AC7420.7010107@plusthree.com>

Stephen Carville wrote:

> Seems to me it makes more sense to embed the session ID or any other
> tracking as hidden variables in a form and send it back as a POST.

This assumes then that every request you make is now a post request. Which means
not more <a> links, just forms. And this also breaks REST style apps (and really
anything that tries to have meaningful HTTP semantics) since POST requests are
for things that could change the data server-side and GET requests are for
anything that won't (idempotent). In this day and age you really have to expect
your users to use cookies. I can understand people not wanting to be tracked
long term, but why should anyone object to memory-only cookies?

-- 
Michael Peters
Developer
Plus Three, LP

From mpeters at plusthree.com  Fri Feb  8 10:28:26 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Fri Feb  8 10:30:33 2008
Subject: [cgiapp] Persistence
In-Reply-To: <1202371223.27200.111.camel@zoe.savage.net.au>
References: <200802031114.29209@centrum.cz>	<002c01c866c1$43330ec0$6401a8c0@lousmaster>	<47A711AD.3070106@plusthree.com>	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>	<1202246282.27200.94.camel@zoe.savage.net.au>	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>	<1202334445.27200.103.camel@zoe.savage.net.au>	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>	<47AA31CF.6010608@plusthree.com>
	<1202371223.27200.111.camel@zoe.savage.net.au>
Message-ID: <47AC751A.8060304@plusthree.com>



Ron Savage wrote:
> On Wed, 2008-02-06 at 17:16 -0500, Michael Peters wrote:
> 
> Hi Michael
> 
>> This is why escaping any data that could potentially come from a user is so
>> important.
> 
> Not just escaping. OP should be warned that server code cannot just rely
> on Javascript-base validation. Someone might disable Javascript and
> sumbit something nasty. That means the validation should be duplicated
> on the server too. And yes, that's a PITA.

Very true. In fact, I almost never do Javascript validation because of this. Why
duplicate my effort? But, it's important to remember that unless you're allowing
your users to submit HTML or JS code, validation is not what prevents XSS. It's
output encoding:

http://www.oreillynet.com/onlamp/blog/2005/10/repeat_after_me_lack_of__outpu.html

-- 
Michael Peters
Developer
Plus Three, LP

From mpeters at plusthree.com  Fri Feb  8 10:40:27 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Fri Feb  8 10:42:36 2008
Subject: [cgiapp] XSS
In-Reply-To: <06483281-05D5-4CFB-B4EF-B99B18BEF917@genetics.utah.edu>
References: <78A40BC4-66B7-4759-9C0C-F9F8BA478B88@genetics.utah.edu>
	<06483281-05D5-4CFB-B4EF-B99B18BEF917@genetics.utah.edu>
Message-ID: <47AC77EB.4000801@plusthree.com>

Barry Moore wrote:

> Basically one version of an XSS attack would be for me to enter
> javascript code into a form on your web page.  Then if you include my
> form submission in other web pages then my javascript could execute on
> any other users machine that subsequently loaded those tainted pages. 
> My JS code could do anything that they could do including contact your
> server on behalf of them and send data back to my server.  Is this correct?

Yes. This is what XSS means. There are variations on this, but it's bascially
the same thing.

> Then the rational for you to html escape any input that comes from me
> and any other user is because that escaping would render the JS code
> in-operable.  Is that correct?

Yes. Imagine you have a form that asks me a survey question and I enter my name as:
  Michael <script>alert("p0wnd!")</script> Peters.

Then you log into the admin side of you application and see my survey result.
You will get p0wnd. Now imagine that I instead of doing a simple alert() I
inserted a <script> tag that pulls in some JS from my own server which adds some
helpful (to me, not you) methods into your page that makes it really easy for me
to get your cookie information and then sends it back to my server. Now I can
log in to your admin side and do whatever I want.

> So then is is safe to assume that if the data from your form never gets
> sent back to other users (i.e. it only gets analyzed by your server -
> such as a search form) or if you check for JS code in some other way,
> then that would also prevent this form of XSS?

No. Imagine this scenario: I use your search form and input some malicious
Javascript. Now I can steal my own information. Not really useful... yet. I
create a URL that will take me to that results page. Something like
http://coolsite.com/search?term=%3Cscript%3Ealert(%22p0wnd!%22)%3C%2Fscript%3E
and I post it in some forum or email group (like this one) and people click on
it. Now I have their information.

-- 
Michael Peters
Developer
Plus Three, LP

From unrtst at gmail.com  Fri Feb  8 14:15:08 2008
From: unrtst at gmail.com (Joshua Miller)
Date: Fri Feb  8 14:15:11 2008
Subject: [cgiapp] Persistence
In-Reply-To: <47AC751A.8060304@plusthree.com>
References: <200802031114.29209@centrum.cz>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<47AA31CF.6010608@plusthree.com>
	<1202371223.27200.111.camel@zoe.savage.net.au>
	<47AC751A.8060304@plusthree.com>
Message-ID: <1b9c12d0802081115j1bf52a64u9682ef84b26fa4fc@mail.gmail.com>

Slightly offtopic plug... there's no extra work to do javascript validation
if using Data::FormValidator for your validation.
http://search.cpan.org/~markstos/Data-FormValidator-4.57/
http://developer.berlios.de/projects/formvalidatorjs/

Makes the user experience much better when they don't have to post data to
your server just to figure out if they formatted their dates correctly and
such.
--
Josh I.

On Feb 8, 2008 10:28 AM, Michael Peters <mpeters@plusthree.com> wrote:

>
>
> Ron Savage wrote:
> > On Wed, 2008-02-06 at 17:16 -0500, Michael Peters wrote:
> >
> > Hi Michael
> >
> >> This is why escaping any data that could potentially come from a user
> is so
> >> important.
> >
> > Not just escaping. OP should be warned that server code cannot just rely
> > on Javascript-base validation. Someone might disable Javascript and
> > sumbit something nasty. That means the validation should be duplicated
> > on the server too. And yes, that's a PITA.
>
> Very true. In fact, I almost never do Javascript validation because of
> this. Why
> duplicate my effort? But, it's important to remember that unless you're
> allowing
> your users to submit HTML or JS code, validation is not what prevents XSS.
> It's
> output encoding:
>
>
> http://www.oreillynet.com/onlamp/blog/2005/10/repeat_after_me_lack_of__outpu.html
>
> --
> Michael Peters
> Developer
> Plus Three, LP
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
From dan.horne at redbone.co.nz  Fri Feb  8 14:47:12 2008
From: dan.horne at redbone.co.nz (Dan Horne)
Date: Fri Feb  8 14:47:23 2008
Subject: [cgiapp] Persistence
In-Reply-To: <7cc7c1ce0802061811x34f0a4aat95caabe8da262ca3@mail.gmail.com>
References: <200802031114.29209@centrum.cz><002c01c866c1$43330ec0$6401a8c0@lousmaster><47A711AD.3070106@plusthree.com><001c01c8673e$d233c2e0$6401a8c0@lousmaster><010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net><1202246282.27200.94.camel@zoe.savage.net.au><039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net><1202334445.27200.103.camel@zoe.savage.net.au><d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com><45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
	<7cc7c1ce0802061811x34f0a4aat95caabe8da262ca3@mail.gmail.com>
Message-ID: <000901c86a8b$66c0aa00$6403a8c0@rdbnnote01>



> -----Original Message-----
> From: Karen
> Sent: Thursday, 7 February 2008 3:12 p.m.
> To: CGI Application
> Subject: Re: [cgiapp] Persistence
> 
> On 2/6/08, Dan Horne <dan.horne@redbone.co.nz> wrote:
> 
> > Another problem is bookmarks. A user may bookmark a page, but when they
> > come back a couple of days later, the session has expired. They might
> also
> > email a link to others, and that link may not work for the same reason.
> 
> If you want a poster child for this particular evilness, and how it
> can be compounded: Joann.com (fabric/craft chain). You get bloggers
> who post links (craftblogging is a big thing), with their session id,
> and when you read and click, you get taken to a page that informs you
> that the session has expired... and it dumps you to the joann.com home
> page. If you're savvy editing the url, you can go back and edit it to
> get there, but otherwise there is absolutely no way to tell where the
> blogger meant you to go.
> 
I've done some work with a Perl-based ecommerce package called ePages that
used to put the sessionid in the URL. They don't do that in the version I
worked with, but there are plenty of sites around that still use the old URL
session approach...


From dan.horne at redbone.co.nz  Fri Feb  8 14:58:12 2008
From: dan.horne at redbone.co.nz (Dan Horne)
Date: Fri Feb  8 14:58:21 2008
Subject: [cgiapp] Persistence
In-Reply-To: <47AC751A.8060304@plusthree.com>
References: <200802031114.29209@centrum.cz>	<002c01c866c1$43330ec0$6401a8c0@lousmaster>	<47A711AD.3070106@plusthree.com>	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>	<1202246282.27200.94.camel@zoe.savage.net.au>	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>	<1202334445.27200.103.camel@zoe.savage.net.au>	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>	<47AA31CF.6010608@plusthree.com><1202371223.27200.111.camel@zoe.savage.net.au>
	<47AC751A.8060304@plusthree.com>
Message-ID: <000b01c86a8c$efbfa8a0$6403a8c0@rdbnnote01>

o
> From: Michael Peters
> Sent: Saturday, 9 February 2008 4:28 a.m.
> To: CGI Application
> Subject: Re: [cgiapp] Persistence
> 
> 
> 
> Ron Savage wrote:
> > On Wed, 2008-02-06 at 17:16 -0500, Michael Peters wrote:
> >
> > Hi Michael
> >
> >> This is why escaping any data that could potentially come from a user
> is so
> >> important.
> >
> > Not just escaping. OP should be warned that server code cannot just rely
> > on Javascript-base validation. Someone might disable Javascript and
> > sumbit something nasty. That means the validation should be duplicated
> > on the server too. And yes, that's a PITA.
> 
> Very true. In fact, I almost never do Javascript validation because of
> this. Why
> duplicate my effort? But, it's important to remember that unless you're
> allowing
> your users to submit HTML or JS code, validation is not what prevents XSS.
> It's
> output encoding:
> 
> http://www.oreillynet.com/onlamp/blog/2005/10/repeat_after_me_lack_of__out
> pu.html
> 

Output encoding is definitely the safest, but I still need users to submit
certain HTML tags, but not others, and I find
Data::FormValidator::Filters::HTMLScrubber does the trick

From bruce at 2MinuteExplainer.com  Fri Feb  8 16:02:28 2008
From: bruce at 2MinuteExplainer.com (Bruce McKenzie)
Date: Fri Feb  8 16:02:29 2008
Subject: [cgiapp] params, params, params...
In-Reply-To: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
Message-ID: <47ACC364.3090006@2MinuteExplainer.com>


Mark Knoop wrote in an email message dated 2/7/2008 5:34 AM:

> 
 > Also I see that CGI::Application has its own params - am I right in
 > thinking these are completeley different to the query params? Is there
 > any relationship between the two? Should I just be using these for
 > 'global' values?

I use a SuperWebApp module as the base for applications, as described in 
the documentation.

This can be used to get and set global items:

$self->param(
         username  => $username,
         host      => $host,
);

later . . .

print $self->param('username');


CGIApp uses CGI.pm, so I get at the form or query data when I need it 
with this (in SuperWebApp.pm)

sub vars {
     my $self = shift;
     return $self->query->Vars;    #ref to cgi params hash
}

It avoids some confusion (for me) to be consistent in naming the params 
from CGI.pm  "$vars" as in
   my $vars = $self->vars;

HTH,

Bruce

-- 
Bruce McKenzie
Business Information Graphics
New York

http://www.2MinuteExplainer.com
From friedo at friedo.com  Fri Feb  8 16:18:46 2008
From: friedo at friedo.com (Mike Friedman)
Date: Fri Feb  8 16:18:48 2008
Subject: [cgiapp] Call for features: CAP::CHI
Message-ID: <cf48d3730802081318l5dead1di48b29bcce58f7cc@mail.gmail.com>

Greetings,

CHI, if you haven't heard of it already, is a new caching framework by
Jonathan Swartz designed to eventually replace Cache::Cache.

  http://search.cpan.org/~jswartz/CHI-0.05/lib/CHI.pm

I am currently soliciting ideas for features that people would like to
see in a CGI-App plugin for CHI. The discussion is on the CHI group
here:

  http://groups.google.com/group/perl-cache-discuss

If you have any ideas, please feel free to chime in there.

When I have some actual code to release, I will cross-post an RFC to
both the CHI group and this list. But, for the sake of my sanity,
let's keep the initial discussion over there for now.

Thanks,


Mike
From barry.moore at genetics.utah.edu  Fri Feb  8 17:49:35 2008
From: barry.moore at genetics.utah.edu (Barry Moore)
Date: Fri Feb  8 17:49:38 2008
Subject: [cgiapp] XSS
In-Reply-To: <47AC77EB.4000801@plusthree.com>
References: <78A40BC4-66B7-4759-9C0C-F9F8BA478B88@genetics.utah.edu>
	<06483281-05D5-4CFB-B4EF-B99B18BEF917@genetics.utah.edu>
	<47AC77EB.4000801@plusthree.com>
Message-ID: <24B25900-5E4D-48CB-9C79-3F50884180E5@genetics.utah.edu>

Thanks Michael - that helps clear things up for me.

B

On Feb 8, 2008, at 8:40 AM, Michael Peters wrote:

> Barry Moore wrote:
>
>> Basically one version of an XSS attack would be for me to enter
>> javascript code into a form on your web page.  Then if you include my
>> form submission in other web pages then my javascript could  
>> execute on
>> any other users machine that subsequently loaded those tainted pages.
>> My JS code could do anything that they could do including contact  
>> your
>> server on behalf of them and send data back to my server.  Is this  
>> correct?
>
> Yes. This is what XSS means. There are variations on this, but it's  
> bascially
> the same thing.
>
>> Then the rational for you to html escape any input that comes from me
>> and any other user is because that escaping would render the JS code
>> in-operable.  Is that correct?
>
> Yes. Imagine you have a form that asks me a survey question and I  
> enter my name as:
>   Michael <script>alert("p0wnd!")</script> Peters.
>
> Then you log into the admin side of you application and see my  
> survey result.
> You will get p0wnd. Now imagine that I instead of doing a simple  
> alert() I
> inserted a <script> tag that pulls in some JS from my own server  
> which adds some
> helpful (to me, not you) methods into your page that makes it  
> really easy for me
> to get your cookie information and then sends it back to my server.  
> Now I can
> log in to your admin side and do whatever I want.
>
>> So then is is safe to assume that if the data from your form never  
>> gets
>> sent back to other users (i.e. it only gets analyzed by your server -
>> such as a search form) or if you check for JS code in some other way,
>> then that would also prevent this form of XSS?
>
> No. Imagine this scenario: I use your search form and input some  
> malicious
> Javascript. Now I can steal my own information. Not really  
> useful... yet. I
> create a URL that will take me to that results page. Something like
> http://coolsite.com/search?term=%3Cscript%3Ealert(%22p0wnd!%22)%3C% 
> 2Fscript%3E
> and I post it in some forum or email group (like this one) and  
> people click on
> it. Now I have their information.
>
> --
> Michael Peters
> Developer
> Plus Three, LP
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>

From ron at savage.net.au  Fri Feb  8 18:56:51 2008
From: ron at savage.net.au (Ron Savage)
Date: Fri Feb  8 18:56:00 2008
Subject: [cgiapp] params, params, params...
In-Reply-To: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
Message-ID: <1202515011.27200.122.camel@zoe.savage.net.au>

On Thu, 2008-02-07 at 10:34 +0000, Mark Knoop wrote:

Hi Mark

> Also I see that CGI::Application has its own params - am I right in thinking 
> these are completeley different to the query params? Is there any 
> relationship between the two? Should I just be using these for 'global' 
> values?
> 
> It also looks like I will be using the session plugin and the session object 
> also has its own params, some of which I would set with the 
> global/query/params that I am interested in.

Perhaps it's clearer if you think in terms of the context of these
various params():

o Query params carry temporary data from the web client to the web
server (i.e. from the user to your app)

o CGI::App params hold temporary data in your app for the duration of
its instantiation

o CGI::Session params hold permanent data (within reason) outside and
beyond the lifetime of one instantiation of your app. Hence they can be
used to pass data from one instantiation to the next, with access keyed
by session id. Hence you need to pass the session key from one
instantiation to the next. Hence our discussion of the various ways in
passing that session id (cookies, hidden form data, rewriting URLs)

So, these params() are not directly related to each other at all.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From mark at rawcane.net  Mon Feb 11 05:03:10 2008
From: mark at rawcane.net (Mark Knoop)
Date: Mon Feb 11 05:03:16 2008
Subject: [cgiapp] params, params, params...
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
	<1202515011.27200.122.camel@zoe.savage.net.au>
Message-ID: <015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>

> On Thu, 2008-02-07 at 10:34 +0000, Mark Knoop wrote:
>
> Hi Mark
>
>> Also I see that CGI::Application has its own params - am I right in 
>> thinking
>> these are completeley different to the query params? Is there any
>> relationship between the two? Should I just be using these for 'global'
>> values?
>>
>> It also looks like I will be using the session plugin and the session 
>> object
>> also has its own params, some of which I would set with the
>> global/query/params that I am interested in.
>
> Perhaps it's clearer if you think in terms of the context of these
> various params():
>
> o Query params carry temporary data from the web client to the web
> server (i.e. from the user to your app)
>
> o CGI::App params hold temporary data in your app for the duration of
> its instantiation
>
> o CGI::Session params hold permanent data (within reason) outside and
> beyond the lifetime of one instantiation of your app. Hence they can be
> used to pass data from one instantiation to the next, with access keyed
> by session id. Hence you need to pass the session key from one
> instantiation to the next. Hence our discussion of the various ways in
> passing that session id (cookies, hidden form data, rewriting URLs)
>
> So, these params() are not directly related to each other at all.

Ok. This is as I thought but it is very useful to have it confirmed in such 
a clear and concise manner.

I am wondering whether it is still useful to set up my own 'globals' object 
with a set of values that are required throughout an instantiation of my 
app, pulled from query params, session params, config and other external 
calls made when the request comes in. This allows me to have some extra 
control over how these values are allocated (eg using the session variables 
if present and obtaining them elsewhere if not, plus performing some 
specific tracing for the getting and setting of certain values) as well as 
allowing me to have a set of class modules which accept a single globals 
object and use whichever specific values are required without me having to 
have lots of different sets of parameters for each one. I'm kinda new to OO 
stuff so I would be interested to know if this is a common practice or if it 
is considered overkill. I have gone down this route and it is working for me 
but I'm not sure it is a good example of encapsulation, loose coupling etc

For example is there another tidy way to make all the params from the 
CGI::App, query and session available in external class methods? Apologies 
if I am being ludicrous due to my lack of understanding of this kind of 
thing but I only learn by asking dumb questions!

Cheers
Mark


From ron at savage.net.au  Tue Feb 12 04:08:56 2008
From: ron at savage.net.au (Ron Savage)
Date: Tue Feb 12 04:07:58 2008
Subject: [cgiapp] params, params, params...
In-Reply-To: <015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
	<1202515011.27200.122.camel@zoe.savage.net.au>
	<015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>
Message-ID: <1202807336.27200.145.camel@zoe.savage.net.au>

On Mon, 2008-02-11 at 10:03 +0000, Mark Knoop wrote:

Hi Mark

> Ok. This is as I thought but it is very useful to have it confirmed in such 
> a clear and concise manner.

Thanx.

> stuff so I would be interested to know if this is a common practice or if it 
> is considered overkill. I have gone down this route and it is working for me 
> but I'm not sure it is a good example of encapsulation, loose coupling etc

It sure sounds like overkill to me.

Having said that, I can understand you might want a variable whose value
happens to come from one of several sources. I think such logic would
fit in your super class, and be stored in CGI::App's param() cache,
rather than inventing another (4th) location for such a cache. That 4
alone tells you it's overkill.

> For example is there another tidy way to make all the params from the 
> CGI::App, query and session available in external class methods? Apologies 
> if I am being ludicrous due to my lack of understanding of this kind of 
> thing but I only learn by asking dumb questions!

The struggle to understand new concepts affects us all, so no, there is
no need to apologize. All you have to do is persist until the situation
is clear. Of course, if it seems clear but really isn't, then you'll
really have something to worry about...

As for external classes, I've had to deal with that. The solution is
simple. At some time you pass the CGI::App object to the other class's
object - either in it's new or just to some particular method of that
object. Then from within that other object you do (using the 2nd
approach):

package OtherClass;

sub metho
{
    my($self, $cgi_obj) = @_;
    ...
    my($value) = $cgi_obj -> param('variable_name');
    ...
}

-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From barry.moore at genetics.utah.edu  Tue Feb 12 14:58:47 2008
From: barry.moore at genetics.utah.edu (Barry Moore)
Date: Tue Feb 12 14:58:50 2008
Subject: [cgiapp] CGIApp Project Management
Message-ID: <BD564309-D5DE-4D8E-B0CE-14E9D08C16CF@genetics.utah.edu>

Hi all,

I've been developing web apps with cgi-app for several years now, but  
for the first time I'm coordinating a project that will involve  
several developers, and I'm trying to think about how best to  
structure things - particularly in regards to version control.

I've got three developers and I'm using subversion to manage code  
versioning.  We are all developing on the same server (RH linux/ 
apache), and our "production" code will be on that same machine as well.


How do those of you with large groups manage having something like  
this in each developers repository:

/home/developer1/my-app-working-copy/cgi-bin/my-app.cgi
                                     /lib/My-App.pm
                                     /templates/home.tt
                                     /css/my-app.css
                                     /html/static.html

distributed to something like this:


/var/www/html/my-app/css/my-app.css
/var/www/html/my-app/html/static.html
/var/www/cgi-bin/my-app/my-app.cgi

I'd also like each developer to be able to run their working copy web  
app off the same server so do you have different cgi-bin paths like  
this:

http://www.our.server/cgi-bin/developer1/my-app.cgi
http://www.our.server/cgi-bin/developer2/my-app.cgi
http://www.our.server/cgi-bin/production/my-app.cgi

Or is it better to configure apache on this machine like this:

http://dev1.our.server/cgi-bin/my-app.cgi
http://dev2.our.server/cgi-bin/my-app.cgi
http://www.our.server/cgi-bin/my-app.cgi

I'm having trouble sorting our what problems to solve with  
environment variables, which with config files and which with apache  
configuration.

B

From dan.horne at redbone.co.nz  Tue Feb 12 15:27:28 2008
From: dan.horne at redbone.co.nz (Dan Horne)
Date: Tue Feb 12 15:27:32 2008
Subject: [cgiapp] CGIApp Project Management
In-Reply-To: <BD564309-D5DE-4D8E-B0CE-14E9D08C16CF@genetics.utah.edu>
References: <BD564309-D5DE-4D8E-B0CE-14E9D08C16CF@genetics.utah.edu>
Message-ID: <27517.210.54.245.44.1202848048.squirrel@mail.redbone.co.nz>

Barry Moore said:
> Hi all,
>
> I've been developing web apps with cgi-app for several years now, but
> for the first time I'm coordinating a project that will involve
> several developers, and I'm trying to think about how best to
> structure things - particularly in regards to version control.
>
> I've got three developers and I'm using subversion to manage code
> versioning.  We are all developing on the same server (RH linux/
> apache), and our "production" code will be on that same machine as well.

When I've worked with multiple developers on CGI::App projects in the
past, we simply installed a copy of the app on our own workstations. It's
the cleanest solution, but it may not be possible for your team.

> How do those of you with large groups manage having something like
> this in each developers repository:
>
> /home/developer1/my-app-working-copy/cgi-bin/my-app.cgi
>                                      /lib/My-App.pm
>                                      /templates/home.tt
>                                      /css/my-app.css
>                                      /html/static.html
>
> distributed to something like this:
>
>
> /var/www/html/my-app/css/my-app.css
> /var/www/html/my-app/html/static.html
> /var/www/cgi-bin/my-app/my-app.cgi
>
> I'd also like each developer to be able to run their working copy web
> app off the same server so do you have different cgi-bin paths like
> this:
>
> http://www.our.server/cgi-bin/developer1/my-app.cgi
> http://www.our.server/cgi-bin/developer2/my-app.cgi
> http://www.our.server/cgi-bin/production/my-app.cgi

That's how I'd do it
>
> Or is it better to configure apache on this machine like this:
>
> http://dev1.our.server/cgi-bin/my-app.cgi
> http://dev2.our.server/cgi-bin/my-app.cgi
> http://www.our.server/cgi-bin/my-app.cgi
>
> I'm having trouble sorting our what problems to solve with
> environment variables, which with config files and which with apache
> configuration.
>

Your config file may need to reside outside of Subversion so that each
developer's configured environment is not updated with the global one. If
your code doesn't have any absolute paths, then things should be fine
(e.g. use Findbin to set the Perl INC path relative to the cgi-bin
directory)


From unrtst at gmail.com  Tue Feb 12 19:25:54 2008
From: unrtst at gmail.com (Joshua Miller)
Date: Tue Feb 12 19:25:57 2008
Subject: [cgiapp] CGIApp Project Management
In-Reply-To: <27517.210.54.245.44.1202848048.squirrel@mail.redbone.co.nz>
References: <BD564309-D5DE-4D8E-B0CE-14E9D08C16CF@genetics.utah.edu>
	<27517.210.54.245.44.1202848048.squirrel@mail.redbone.co.nz>
Message-ID: <1b9c12d0802121625r660693cfyc980bb2199d2193f@mail.gmail.com>

Developing on a central server is nice for dmz'd db access, and it saves
each dev from installing all the perl libs, apache, etc, on their own box
(or vm).

However, you'll have issues with multiple versions of libraries if running
like:

> http://www.our.server/cgi-bin/developer1/my-app.cgi
> http://www.our.server/cgi-bin/developer2/my-app.cgi
> http://www.our.server/cgi-bin/production/my-app.cgi

(unless that's a proxy to separate backend apache mod_perl processes)

Separate vhosts have similar issues.

I've split ours to separate apache instances, with high ports:

> http://www.our.server:8081/cgi-bin/developer1/my-app.cgi<http://www.our.server/cgi-bin/developer1/my-app.cgi>
> http://www.our.server:8082/cgi-bin/developer2/my-app.cgi<http://www.our.server/cgi-bin/developer2/my-app.cgi>
> http://www.our.server:8083/cgi-bin/production/my-app.cgi<http://www.our.server/cgi-bin/production/my-app.cgi>

Actually, we give each dev a range of 10 ports, so they can run multiple
versions of the app side by side. Just throw together a little apachectl
wrapper, and a base apache config, so they just have to include the base
config, and set a handful of vars to get their instance up.
Then they can start/stop their instance on their own, and no worries about
contaminated env or writing/reading someone elses files.

For version control, deciding on the merge approach usually answers most of
the related questions. See this for a starter background:
http://cvsbook.red-bean.com/cvsbook.html#The%20Dovetail%20Approach%20--%20Merging%20In%20And%20Out%20Of%20The%20Trunk
http://cvsbook.red-bean.com/cvsbook.html#The%20Flying%20Fish%20Approach%20--%20A%20Simpler%20Way%20To%20Do%20It

My 2cents... hope it helps, and good luck,
--
Josh I.

On Feb 12, 2008 3:27 PM, Dan Horne <dan.horne@redbone.co.nz> wrote:

> Barry Moore said:
> > Hi all,
> >
> > I've been developing web apps with cgi-app for several years now, but
> > for the first time I'm coordinating a project that will involve
> > several developers, and I'm trying to think about how best to
> > structure things - particularly in regards to version control.
> >
> > I've got three developers and I'm using subversion to manage code
> > versioning.  We are all developing on the same server (RH linux/
> > apache), and our "production" code will be on that same machine as well.
>
> When I've worked with multiple developers on CGI::App projects in the
> past, we simply installed a copy of the app on our own workstations. It's
> the cleanest solution, but it may not be possible for your team.
>
> > How do those of you with large groups manage having something like
> > this in each developers repository:
> >
> > /home/developer1/my-app-working-copy/cgi-bin/my-app.cgi
> >                                      /lib/My-App.pm
> >                                      /templates/home.tt
> >                                      /css/my-app.css
> >                                      /html/static.html
> >
> > distributed to something like this:
> >
> >
> > /var/www/html/my-app/css/my-app.css
> > /var/www/html/my-app/html/static.html
> > /var/www/cgi-bin/my-app/my-app.cgi
> >
> > I'd also like each developer to be able to run their working copy web
> > app off the same server so do you have different cgi-bin paths like
> > this:
> >
> > http://www.our.server/cgi-bin/developer1/my-app.cgi
> > http://www.our.server/cgi-bin/developer2/my-app.cgi
> > http://www.our.server/cgi-bin/production/my-app.cgi
>
> That's how I'd do it
> >
> > Or is it better to configure apache on this machine like this:
> >
> > http://dev1.our.server/cgi-bin/my-app.cgi
> > http://dev2.our.server/cgi-bin/my-app.cgi
> > http://www.our.server/cgi-bin/my-app.cgi
> >
> > I'm having trouble sorting our what problems to solve with
> > environment variables, which with config files and which with apache
> > configuration.
> >
>
> Your config file may need to reside outside of Subversion so that each
> developer's configured environment is not updated with the global one. If
> your code doesn't have any absolute paths, then things should be fine
> (e.g. use Findbin to set the Perl INC path relative to the cgi-bin
> directory)
>
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
From azfuller at gmail.com  Tue Feb 12 20:06:59 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Tue Feb 12 20:07:01 2008
Subject: [cgiapp] CGIApp Project Management
In-Reply-To: <1b9c12d0802121625r660693cfyc980bb2199d2193f@mail.gmail.com>
References: <BD564309-D5DE-4D8E-B0CE-14E9D08C16CF@genetics.utah.edu>
	<27517.210.54.245.44.1202848048.squirrel@mail.redbone.co.nz>
	<1b9c12d0802121625r660693cfyc980bb2199d2193f@mail.gmail.com>
Message-ID: <d69cc4a60802121706q62690d65nc8ec943fb01af0e5@mail.gmail.com>

On Feb 12, 2008 5:25 PM, Joshua Miller <unrtst@gmail.com> wrote:
> Developing on a central server is nice for dmz'd db access, and it saves
> each dev from installing all the perl libs, apache, etc, on their own box
> (or vm).

There's also CGI::Application::Server (which uses
HTTP::Server::Simple). It works like Catalyst's development server. A
quick-and-dirty (local) HTTP server to develop at your desktop. If the
design isn't dependent upon Apache features, that might work well.

It has some dependencies on mechanize. I don't understand why. I used
HTTP::Server::Simple, stole some stuff out of C::A::Server (to
subclass H::T::T::CGI the same way C::A::Server does), and it worked
fine.

Mark
From mark at rawcane.net  Wed Feb 13 18:29:54 2008
From: mark at rawcane.net (Mark Knoop)
Date: Wed Feb 13 18:30:00 2008
Subject: [cgiapp] params, params, params...
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net><1202515011.27200.122.camel@zoe.savage.net.au><015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>
	<1202807336.27200.145.camel@zoe.savage.net.au>
Message-ID: <00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>

>
> Having said that, I can understand you might want a variable whose value
> happens to come from one of several sources. I think such logic would
> fit in your super class, and be stored in CGI::App's param() cache,
> rather than inventing another (4th) location for such a cache. That 4
> alone tells you it's overkill.
>

Is it bad policy to add properties to the CGI::App itself?

eg saying

$self->{my_special_value} = 'SOME_VALUE';

instead of

$self->param(my_special_value, 'SOME_VALUE');

?

I guess it is bad policy otherwise the params method would not exist but it 
would be useful to understand exactly why this is?

Cheers
Mark 

From hitz at genome.stanford.edu  Wed Feb 13 18:33:38 2008
From: hitz at genome.stanford.edu (Ben Hitz)
Date: Wed Feb 13 18:33:40 2008
Subject: [cgiapp] params, params, params...
In-Reply-To: <00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net><1202515011.27200.122.camel@zoe.savage.net.au><015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>
	<1202807336.27200.145.camel@zoe.savage.net.au>
	<00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>
Message-ID: <AB334EF3-4B91-4E03-B47A-CFD8F6D10242@genome.stanford.edu>



I do this but for stuff that is NOT a cgi parameter, like a reference  
to another object.

Ben
On Feb 13, 2008, at 3:29 PM, Mark Knoop wrote:

>>
>> Having said that, I can understand you might want a variable whose  
>> value
>> happens to come from one of several sources. I think such logic would
>> fit in your super class, and be stored in CGI::App's param() cache,
>> rather than inventing another (4th) location for such a cache. That 4
>> alone tells you it's overkill.
>>
>
> Is it bad policy to add properties to the CGI::App itself?
>
> eg saying
>
> $self->{my_special_value} = 'SOME_VALUE';
>
> instead of
>
> $self->param(my_special_value, 'SOME_VALUE');
>
> ?
>
> I guess it is bad policy otherwise the params method would not  
> exist but it would be useful to understand exactly why this is?
>
> Cheers
> Mark
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################

--
Ben Hitz
Senior Scientific Programmer ** Saccharomyces Genome Database ** GO  
Consortium
Stanford University ** hitz@genome.stanford.edu



From unrtst at gmail.com  Wed Feb 13 18:40:27 2008
From: unrtst at gmail.com (Joshua Miller)
Date: Wed Feb 13 18:40:29 2008
Subject: [cgiapp] params, params, params...
In-Reply-To: <00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
	<1202515011.27200.122.camel@zoe.savage.net.au>
	<015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>
	<1202807336.27200.145.camel@zoe.savage.net.au>
	<00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>
Message-ID: <1b9c12d0802131540k7d23d3bfofafa660b9c8f2dd5@mail.gmail.com>

On Feb 13, 2008 6:29 PM, Mark Knoop <mark@rawcane.net> wrote:

> >
> > Having said that, I can understand you might want a variable whose value
> > happens to come from one of several sources. I think such logic would
> > fit in your super class, and be stored in CGI::App's param() cache,
> > rather than inventing another (4th) location for such a cache. That 4
> > alone tells you it's overkill.
> >
>
> Is it bad policy to add properties to the CGI::App itself?
>
> eg saying
>
> $self->{my_special_value} = 'SOME_VALUE';


Yes, that's bad. You can technically do it, but you should tread lightly,
and be aware of the possible consequences. CGI::App is currently based on a
blessed hash, but that might not always be the case (though it's likely to
stay that way). It could move to an inside-out object, or array based, etc.
Also, it uses that to store stuff itself. When you call param, it sets those
in $self->{__PARAMS} hash. If your my_special_value was "__PARAMS", you'd
overwrite the internal __PARAMS hash, and break CGI::App.

As an example, the CGI::App perldoc PLUG-INS section...
       Writing Plug-ins

       Writing plug-ins is simple. Simply create a new package, and export
the methods that you
       want to become part of a CGI::Application project. See
CGI::Application::Plugin::Vali?
       dateRM for an example.

       In order to avoid namespace conflicts within a CGI::Application
object, plugin developers
       are recommended to use a unique prefix, such as the name of plugin
package, when storing
       information. For instance:

        $app->{__PARAM} = 'foo'; # BAD! Could conflict.
        $app->{'MyPlugin::Module::__PARAM'} = 'foo'; # Good.
        $app->{'MyPlugin::Module'}{__PARAM} = 'foo'; # Good.

So if you're going to do it, be careful.


>
>
> instead of
>
> $self->param(my_special_value, 'SOME_VALUE');

?
>
> I guess it is bad policy otherwise the params method would not exist but
> it
> would be useful to understand exactly why this is?
>
> Cheers
> Mark
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
From lhernsen1015 at wowway.com  Wed Feb 13 19:19:47 2008
From: lhernsen1015 at wowway.com (Lou Hernsen)
Date: Wed Feb 13 19:23:52 2008
Subject: [cgiapp] Program format (this is the way I write my code -help?)
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net><1202515011.27200.122.camel@zoe.savage.net.au><015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net><1202807336.27200.145.camel@zoe.savage.net.au>
	<00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>
Message-ID: <003001c86e9f$71735b60$6401a8c0@lousmaster>

Hallo
I am writing an online game. I have a main .cgi and am using packages which
are "required" as needed.
My .cgi is one long if-elsif-else all based on what action you make in the
game. I do it this way so I can complete one packet at a time to do a
certain thing.
All files are read in the .cgi and vars passes to packages as needed..... am
I even close in my method?

>>>>>Mind you, this is a hobby to me.. all self taught....<<<<<<<

ANY suggestion for books on program format would be helpfull.. thanks
comments welcome.. try not to grind me into the dust, please LOL
thanks
Lou

here is an example.

 if ($Input{Action} eq "Log In")
 {
  $Pm{Status}=Login::LogIn("$Input{Name}","$Input{PW}");
  exit;
 }
 elsif ($Input{Action} eq "New Player")
 {
  Login::NewPlayer();
  exit;
 }
 elsif ($Input{Action} eq "Create Player")
 {
  Login::CreatePlayer("$Input{Name}","$Input{PW},"$Input{Gender}";
  exit;
 }
 elsif ($Input{Action} eq "EmailLogin")
 {
  $Pm{Status}=Login::EmailLogin("$Input{Name}","$Input{SN}");
  exit;
 }

From stewart.heckenberg at gmail.com  Wed Feb 13 19:29:09 2008
From: stewart.heckenberg at gmail.com (Stewart Heckenberg)
Date: Wed Feb 13 19:29:12 2008
Subject: [cgiapp] Program format (this is the way I write my code -help?)
In-Reply-To: <003001c86e9f$71735b60$6401a8c0@lousmaster>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
	<1202515011.27200.122.camel@zoe.savage.net.au>
	<015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>
	<1202807336.27200.145.camel@zoe.savage.net.au>
	<00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>
	<003001c86e9f$71735b60$6401a8c0@lousmaster>
Message-ID: <45ba9f350802131629y74f5930fl54a41b489beee037@mail.gmail.com>

Hi Lou,

Actually you're close, but not close enough :)

cgiapp actually allows you to get rid of all your if/else logic and
instead use what are called "run modes", which in terms of your games
are all the action/packets, e.g. instead of:

 if ($Input{Action} eq "Log In")

you would use:

sub login {...

and to trigger that sub to run, you set a query parameter called "rm"
to be "login", e.g. foo.cgi?rm=login

That's how cgiapp works -- instead of if/else blocks for your logic,
you use subs, and to execute a particular sub you merely set the rm
param to be the name of that runmode/sub. Have a look at the cgiapp
documentation for some examples.

Hope this helps :)

Kind regards,
Stew

On 14/02/2008, Lou Hernsen <lhernsen1015@wowway.com> wrote:
> Hallo
> I am writing an online game. I have a main .cgi and am using packages which
> are "required" as needed.
> My .cgi is one long if-elsif-else all based on what action you make in the
> game. I do it this way so I can complete one packet at a time to do a
> certain thing.
> All files are read in the .cgi and vars passes to packages as needed..... am
> I even close in my method?
>
> >>>>>Mind you, this is a hobby to me.. all self taught....<<<<<<<
>
> ANY suggestion for books on program format would be helpfull.. thanks
> comments welcome.. try not to grind me into the dust, please LOL
> thanks
> Lou
>
> here is an example.
>
>  if ($Input{Action} eq "Log In")
>  {
>   $Pm{Status}=Login::LogIn("$Input{Name}","$Input{PW}");
>   exit;
>  }
>  elsif ($Input{Action} eq "New Player")
>  {
>   Login::NewPlayer();
>   exit;
>  }
>  elsif ($Input{Action} eq "Create Player")
>  {
>   Login::CreatePlayer("$Input{Name}","$Input{PW},"$Input{Gender}";
>   exit;
>  }
>  elsif ($Input{Action} eq "EmailLogin")
>  {
>   $Pm{Status}=Login::EmailLogin("$Input{Name}","$Input{SN}");
>   exit;
>  }
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
From lhernsen1015 at wowway.com  Wed Feb 13 19:33:52 2008
From: lhernsen1015 at wowway.com (Lou Hernsen)
Date: Wed Feb 13 19:37:04 2008
Subject: [cgiapp] Program format (this is the way I write my code -help?)
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net><1202515011.27200.122.camel@zoe.savage.net.au><015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net><1202807336.27200.145.camel@zoe.savage.net.au><00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net><003001c86e9f$71735b60$6401a8c0@lousmaster>
	<45ba9f350802131629y74f5930fl54a41b489beee037@mail.gmail.com>
Message-ID: <001601c86ea1$4a06aa80$6401a8c0@lousmaster>

I sorta understand....and then not..

The last program I wrote was 10K+ line long where I used only subroutines
all in one cgi....
I was told I was nuts for doing that... now I am rewritting everything over
again... and using some
new things I have learned about.... I will google some of the words you used
.. and see what i get.

Is what your talking about called "object oriented"?

thanks for the help...
still lost but looking :)
Lou


----- Original Message ----- 
From: "Stewart Heckenberg" <stewart.heckenberg@gmail.com>
To: "CGI Application" <cgiapp@lists.erlbaum.net>
Sent: Wednesday, February 13, 2008 7:29 PM
Subject: Re: [cgiapp] Program format (this is the way I write my
code -help?)


> Hi Lou,
>
> Actually you're close, but not close enough :)
>
> cgiapp actually allows you to get rid of all your if/else logic and
> instead use what are called "run modes", which in terms of your games
> are all the action/packets, e.g. instead of:
>
>  if ($Input{Action} eq "Log In")
>
> you would use:
>
> sub login {...
>
> and to trigger that sub to run, you set a query parameter called "rm"
> to be "login", e.g. foo.cgi?rm=login
>
> That's how cgiapp works -- instead of if/else blocks for your logic,
> you use subs, and to execute a particular sub you merely set the rm
> param to be the name of that runmode/sub. Have a look at the cgiapp
> documentation for some examples.
>
> Hope this helps :)
>
> Kind regards,
> Stew
>
> On 14/02/2008, Lou Hernsen <lhernsen1015@wowway.com> wrote:
> > Hallo
> > I am writing an online game. I have a main .cgi and am using packages
which
> > are "required" as needed.
> > My .cgi is one long if-elsif-else all based on what action you make in
the
> > game. I do it this way so I can complete one packet at a time to do a
> > certain thing.
> > All files are read in the .cgi and vars passes to packages as
needed..... am
> > I even close in my method?
> >
> > >>>>>Mind you, this is a hobby to me.. all self taught....<<<<<<<
> >
> > ANY suggestion for books on program format would be helpfull.. thanks
> > comments welcome.. try not to grind me into the dust, please LOL
> > thanks
> > Lou
> >
> > here is an example.
> >
> >  if ($Input{Action} eq "Log In")
> >  {
> >   $Pm{Status}=Login::LogIn("$Input{Name}","$Input{PW}");
> >   exit;
> >  }
> >  elsif ($Input{Action} eq "New Player")
> >  {
> >   Login::NewPlayer();
> >   exit;
> >  }
> >  elsif ($Input{Action} eq "Create Player")
> >  {
> >   Login::CreatePlayer("$Input{Name}","$Input{PW},"$Input{Gender}";
> >   exit;
> >  }
> >  elsif ($Input{Action} eq "EmailLogin")
> >  {
> >   $Pm{Status}=Login::EmailLogin("$Input{Name}","$Input{SN}");
> >   exit;
> >  }
> >
> >
> > #####  CGI::Application community mailing list  ################
> > ##                                                            ##
> > ##  To unsubscribe, or change your message delivery options,  ##
> > ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> > ##                                                            ##
> > ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> > ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> > ##                                                            ##
> > ################################################################
> >
> >
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.20.4/1275 - Release Date: 2/12/08
3:20 PM
>
>

From stewart.heckenberg at gmail.com  Wed Feb 13 19:45:42 2008
From: stewart.heckenberg at gmail.com (Stewart Heckenberg)
Date: Wed Feb 13 19:45:44 2008
Subject: [cgiapp] Program format (this is the way I write my code -help?)
In-Reply-To: <001601c86ea1$4a06aa80$6401a8c0@lousmaster>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
	<1202515011.27200.122.camel@zoe.savage.net.au>
	<015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>
	<1202807336.27200.145.camel@zoe.savage.net.au>
	<00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>
	<003001c86e9f$71735b60$6401a8c0@lousmaster>
	<45ba9f350802131629y74f5930fl54a41b489beee037@mail.gmail.com>
	<001601c86ea1$4a06aa80$6401a8c0@lousmaster>
Message-ID: <45ba9f350802131645nbecc03ai4702f2abc2834d83@mail.gmail.com>

cgiapp is object-oriented, but you don't have to worry about that too
much with what you're doing. The main thing to focus on is that
instead of testing whether $input{action} eq 'some_action', you
instead have a sub called 'some_action'.

So your if/else blocks become subs, and instead the 'action' input
param being set to 'some_action' set the 'rm' cgi query param to
'some_action' instead. All the rest of your code remains the same
apart from this.

See http://search.cpan.org/~markstos/CGI-Application-4.06/lib/CGI/Application.pm

Stew

On 14/02/2008, Lou Hernsen <lhernsen1015@wowway.com> wrote:
> I sorta understand....and then not..
>
> The last program I wrote was 10K+ line long where I used only subroutines
> all in one cgi....
> I was told I was nuts for doing that... now I am rewritting everything over
> again... and using some
> new things I have learned about.... I will google some of the words you used
> .. and see what i get.
>
> Is what your talking about called "object oriented"?
>
> thanks for the help...
> still lost but looking :)
> Lou
>
>
> ----- Original Message -----
> From: "Stewart Heckenberg" <stewart.heckenberg@gmail.com>
> To: "CGI Application" <cgiapp@lists.erlbaum.net>
> Sent: Wednesday, February 13, 2008 7:29 PM
> Subject: Re: [cgiapp] Program format (this is the way I write my
> code -help?)
>
>
> > Hi Lou,
> >
> > Actually you're close, but not close enough :)
> >
> > cgiapp actually allows you to get rid of all your if/else logic and
> > instead use what are called "run modes", which in terms of your games
> > are all the action/packets, e.g. instead of:
> >
> >  if ($Input{Action} eq "Log In")
> >
> > you would use:
> >
> > sub login {...
> >
> > and to trigger that sub to run, you set a query parameter called "rm"
> > to be "login", e.g. foo.cgi?rm=login
> >
> > That's how cgiapp works -- instead of if/else blocks for your logic,
> > you use subs, and to execute a particular sub you merely set the rm
> > param to be the name of that runmode/sub. Have a look at the cgiapp
> > documentation for some examples.
> >
> > Hope this helps :)
> >
> > Kind regards,
> > Stew
> >
> > On 14/02/2008, Lou Hernsen <lhernsen1015@wowway.com> wrote:
> > > Hallo
> > > I am writing an online game. I have a main .cgi and am using packages
> which
> > > are "required" as needed.
> > > My .cgi is one long if-elsif-else all based on what action you make in
> the
> > > game. I do it this way so I can complete one packet at a time to do a
> > > certain thing.
> > > All files are read in the .cgi and vars passes to packages as
> needed..... am
> > > I even close in my method?
> > >
> > > >>>>>Mind you, this is a hobby to me.. all self taught....<<<<<<<
> > >
> > > ANY suggestion for books on program format would be helpfull.. thanks
> > > comments welcome.. try not to grind me into the dust, please LOL
> > > thanks
> > > Lou
> > >
> > > here is an example.
> > >
> > >  if ($Input{Action} eq "Log In")
> > >  {
> > >   $Pm{Status}=Login::LogIn("$Input{Name}","$Input{PW}");
> > >   exit;
> > >  }
> > >  elsif ($Input{Action} eq "New Player")
> > >  {
> > >   Login::NewPlayer();
> > >   exit;
> > >  }
> > >  elsif ($Input{Action} eq "Create Player")
> > >  {
> > >   Login::CreatePlayer("$Input{Name}","$Input{PW},"$Input{Gender}";
> > >   exit;
> > >  }
> > >  elsif ($Input{Action} eq "EmailLogin")
> > >  {
> > >   $Pm{Status}=Login::EmailLogin("$Input{Name}","$Input{SN}");
> > >   exit;
> > >  }
> > >
> > >
> > > #####  CGI::Application community mailing list  ################
> > > ##                                                            ##
> > > ##  To unsubscribe, or change your message delivery options,  ##
> > > ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> > > ##                                                            ##
> > > ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> > > ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> > > ##                                                            ##
> > > ################################################################
> > >
> > >
> >
> > #####  CGI::Application community mailing list  ################
> > ##                                                            ##
> > ##  To unsubscribe, or change your message delivery options,  ##
> > ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> > ##                                                            ##
> > ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> > ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> > ##                                                            ##
> > ################################################################
> >
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.516 / Virus Database: 269.20.4/1275 - Release Date: 2/12/08
> 3:20 PM
> >
> >
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
From azfuller at gmail.com  Wed Feb 13 20:01:55 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Wed Feb 13 20:01:57 2008
Subject: [cgiapp] Program format (this is the way I write my code -help?)
In-Reply-To: <001601c86ea1$4a06aa80$6401a8c0@lousmaster>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
	<1202515011.27200.122.camel@zoe.savage.net.au>
	<015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>
	<1202807336.27200.145.camel@zoe.savage.net.au>
	<00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>
	<003001c86e9f$71735b60$6401a8c0@lousmaster>
	<45ba9f350802131629y74f5930fl54a41b489beee037@mail.gmail.com>
	<001601c86ea1$4a06aa80$6401a8c0@lousmaster>
Message-ID: <d69cc4a60802131701g7e698c03o247025a48cddc4d@mail.gmail.com>

On Feb 13, 2008 5:33 PM, Lou Hernsen <lhernsen1015@wowway.com> wrote:
> I sorta understand....and then not..

It takes awhile to get your head around how C::A works (or, maybe
objects generally). Read these. Maybe they'll get you thinking in the
right direction.

http://www.sitepoint.com/article/cgi-application

http://www.perl.com/pub/a/2001/06/05/cgi.html

Mark
From lhernsen1015 at wowway.com  Wed Feb 13 19:59:51 2008
From: lhernsen1015 at wowway.com (Lou Hernsen)
Date: Wed Feb 13 20:03:46 2008
Subject: [cgiapp] Program format (this is the way I write my code -help?)
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net><1202515011.27200.122.camel@zoe.savage.net.au><015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net><1202807336.27200.145.camel@zoe.savage.net.au><00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net><003001c86e9f$71735b60$6401a8c0@lousmaster><45ba9f350802131629y74f5930fl54a41b489beee037@mail.gmail.com><001601c86ea1$4a06aa80$6401a8c0@lousmaster>
	<45ba9f350802131645nbecc03ai4702f2abc2834d83@mail.gmail.com>
Message-ID: <004c01c86ea5$04ffeec0$6401a8c0@lousmaster>

ok great.. I think i'm getting it.

this must be the answer to the select case question I heard about years
ago...
While I get my brain to absorb this new stuff.. may I ask you to just
tranlate just one item for me?
# package name is LogIn.pl ( i was told to use .pl for packages, .pm for
modules)
# is in Game.cgi
if ($Input{Action} eq "Log In")
    {
     $Pm{Status}=Login::LogIn("$Input{Name}","$Input{PW}");
    exit;
    }

###### AH HA! I only need to put "1;" at the end on a package, not "return
1";
thanks....
Lou




----- Original Message ----- 
From: "Stewart Heckenberg" <stewart.heckenberg@gmail.com>
To: "CGI Application" <cgiapp@lists.erlbaum.net>
Sent: Wednesday, February 13, 2008 7:45 PM
Subject: Re: [cgiapp] Program format (this is the way I write my
code -help?)


> cgiapp is object-oriented, but you don't have to worry about that too
> much with what you're doing. The main thing to focus on is that
> instead of testing whether $input{action} eq 'some_action', you
> instead have a sub called 'some_action'.
>
> So your if/else blocks become subs, and instead the 'action' input
> param being set to 'some_action' set the 'rm' cgi query param to
> 'some_action' instead. All the rest of your code remains the same
> apart from this.
>
> See
http://search.cpan.org/~markstos/CGI-Application-4.06/lib/CGI/Application.pm
>
> Stew
>
> On 14/02/2008, Lou Hernsen <lhernsen1015@wowway.com> wrote:
> > I sorta understand....and then not..
> >
> > The last program I wrote was 10K+ line long where I used only
subroutines
> > all in one cgi....
> > I was told I was nuts for doing that... now I am rewritting everything
over
> > again... and using some
> > new things I have learned about.... I will google some of the words you
used
> > .. and see what i get.
> >
> > Is what your talking about called "object oriented"?
> >
> > thanks for the help...
> > still lost but looking :)
> > Lou
> >
> >
> > ----- Original Message -----
> > From: "Stewart Heckenberg" <stewart.heckenberg@gmail.com>
> > To: "CGI Application" <cgiapp@lists.erlbaum.net>
> > Sent: Wednesday, February 13, 2008 7:29 PM
> > Subject: Re: [cgiapp] Program format (this is the way I write my
> > code -help?)
> >
> >
> > > Hi Lou,
> > >
> > > Actually you're close, but not close enough :)
> > >
> > > cgiapp actually allows you to get rid of all your if/else logic and
> > > instead use what are called "run modes", which in terms of your games
> > > are all the action/packets, e.g. instead of:
> > >
> > >  if ($Input{Action} eq "Log In")
> > >
> > > you would use:
> > >
> > > sub login {...
> > >
> > > and to trigger that sub to run, you set a query parameter called "rm"
> > > to be "login", e.g. foo.cgi?rm=login
> > >
> > > That's how cgiapp works -- instead of if/else blocks for your logic,
> > > you use subs, and to execute a particular sub you merely set the rm
> > > param to be the name of that runmode/sub. Have a look at the cgiapp
> > > documentation for some examples.
> > >
> > > Hope this helps :)
> > >
> > > Kind regards,
> > > Stew
> > >
> > > On 14/02/2008, Lou Hernsen <lhernsen1015@wowway.com> wrote:
> > > > Hallo
> > > > I am writing an online game. I have a main .cgi and am using
packages
> > which
> > > > are "required" as needed.
> > > > My .cgi is one long if-elsif-else all based on what action you make
in
> > the
> > > > game. I do it this way so I can complete one packet at a time to do
a
> > > > certain thing.
> > > > All files are read in the .cgi and vars passes to packages as
> > needed..... am
> > > > I even close in my method?
> > > >
> > > > >>>>>Mind you, this is a hobby to me.. all self taught....<<<<<<<
> > > >
> > > > ANY suggestion for books on program format would be helpfull..
thanks
> > > > comments welcome.. try not to grind me into the dust, please LOL
> > > > thanks
> > > > Lou
> > > >
> > > > here is an example.
> > > >
> > > >  if ($Input{Action} eq "Log In")
> > > >  {
> > > >   $Pm{Status}=Login::LogIn("$Input{Name}","$Input{PW}");
> > > >   exit;
> > > >  }
> > > >  elsif ($Input{Action} eq "New Player")
> > > >  {
> > > >   Login::NewPlayer();
> > > >   exit;
> > > >  }
> > > >  elsif ($Input{Action} eq "Create Player")
> > > >  {
> > > >   Login::CreatePlayer("$Input{Name}","$Input{PW},"$Input{Gender}";
> > > >   exit;
> > > >  }
> > > >  elsif ($Input{Action} eq "EmailLogin")
> > > >  {
> > > >   $Pm{Status}=Login::EmailLogin("$Input{Name}","$Input{SN}");
> > > >   exit;
> > > >  }
> > > >
> > > >
> > > > #####  CGI::Application community mailing list  ################
> > > > ##                                                            ##
> > > > ##  To unsubscribe, or change your message delivery options,  ##
> > > > ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> > > > ##                                                            ##
> > > > ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> > > > ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> > > > ##                                                            ##
> > > > ################################################################
> > > >
> > > >
> > >
> > > #####  CGI::Application community mailing list  ################
> > > ##                                                            ##
> > > ##  To unsubscribe, or change your message delivery options,  ##
> > > ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> > > ##                                                            ##
> > > ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> > > ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> > > ##                                                            ##
> > > ################################################################
> > >
> > >
> > >
> > > --
> > > No virus found in this incoming message.
> > > Checked by AVG Free Edition.
> > > Version: 7.5.516 / Virus Database: 269.20.4/1275 - Release Date:
2/12/08
> > 3:20 PM
> > >
> > >
> >
> >
> > #####  CGI::Application community mailing list  ################
> > ##                                                            ##
> > ##  To unsubscribe, or change your message delivery options,  ##
> > ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> > ##                                                            ##
> > ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> > ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> > ##                                                            ##
> > ################################################################
> >
> >
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.20.4/1275 - Release Date: 2/12/08
3:20 PM
>
>

From lhernsen1015 at wowway.com  Wed Feb 13 20:02:17 2008
From: lhernsen1015 at wowway.com (Lou Hernsen)
Date: Wed Feb 13 20:05:49 2008
Subject: [cgiapp] Program format (this is the way I write my code -help?)
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net><1202515011.27200.122.camel@zoe.savage.net.au><015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net><1202807336.27200.145.camel@zoe.savage.net.au><00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net><003001c86e9f$71735b60$6401a8c0@lousmaster><45ba9f350802131629y74f5930fl54a41b489beee037@mail.gmail.com><001601c86ea1$4a06aa80$6401a8c0@lousmaster>
	<d69cc4a60802131701g7e698c03o247025a48cddc4d@mail.gmail.com>
Message-ID: <005401c86ea5$4e334060$6401a8c0@lousmaster>

Ok thanks.. reading.. absorbing... percieving but still not grokking...
Lou


----- Original Message ----- 
From: "Mark Fuller" <azfuller@gmail.com>
To: "CGI Application" <cgiapp@lists.erlbaum.net>
Sent: Wednesday, February 13, 2008 8:01 PM
Subject: Re: [cgiapp] Program format (this is the way I write my
code -help?)


> On Feb 13, 2008 5:33 PM, Lou Hernsen <lhernsen1015@wowway.com> wrote:
> > I sorta understand....and then not..
>
> It takes awhile to get your head around how C::A works (or, maybe
> objects generally). Read these. Maybe they'll get you thinking in the
> right direction.
>
> http://www.sitepoint.com/article/cgi-application
>
> http://www.perl.com/pub/a/2001/06/05/cgi.html
>
> Mark
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.20.4/1275 - Release Date: 2/12/08
3:20 PM
>
>

From azfuller at gmail.com  Wed Feb 13 20:16:56 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Wed Feb 13 20:16:57 2008
Subject: [cgiapp] Program format (this is the way I write my code -help?)
In-Reply-To: <005401c86ea5$4e334060$6401a8c0@lousmaster>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net>
	<1202515011.27200.122.camel@zoe.savage.net.au>
	<015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net>
	<1202807336.27200.145.camel@zoe.savage.net.au>
	<00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net>
	<003001c86e9f$71735b60$6401a8c0@lousmaster>
	<45ba9f350802131629y74f5930fl54a41b489beee037@mail.gmail.com>
	<001601c86ea1$4a06aa80$6401a8c0@lousmaster>
	<d69cc4a60802131701g7e698c03o247025a48cddc4d@mail.gmail.com>
	<005401c86ea5$4e334060$6401a8c0@lousmaster>
Message-ID: <d69cc4a60802131716w73e6578as589b4b8abb7e3367@mail.gmail.com>

On Feb 13, 2008 6:02 PM, Lou Hernsen <lhernsen1015@wowway.com> wrote:
> Ok thanks.. reading.. absorbing... percieving but still not grokking...

The run modes that were mentioned are just a way to abstract the URL
to a subroutine to handle whatever action is associated with that URL.
C::A does the "if/else" logic for you. You just have to register the
URL (either a parameter on the URL, or in the POSTed form) and
associate it with a subroutine. When the application is invoked with
that parameter (or form value) it will automatically call the
subroutine.

If you read those two articles you'll get the idea.

There's a plug-in that might make it easier for you (but, I personally
like traditional run modes):

http://search.cpan.org/~jaywhy/CGI-Application-Plugin-ActionDispatch-0.91/lib/CGI/Application/Plugin/ActionDispatch.pm

This lets you specify the URL with each subroutine. If the URL
matches, that's the subroutine that's executed. No run modes.

Mark
From david at espiral.org.mx  Wed Feb 13 21:01:05 2008
From: david at espiral.org.mx (David Moreno)
Date: Wed Feb 13 21:01:07 2008
Subject: [cgiapp] Poll: What's your favorite CGI-App plugin and why?
Message-ID: <144c024a0802131801i38274aacq509879645362ae38@mail.gmail.com>

Hi :)

I'd like to start a little poll about what are people's favorite CGI-App
plugins and why.

I'll start.

After making two big applications with CGI-App (actually, currently doing my
second big one), I've found that CGI::Application::Plugin::TT is my favorite
plugin on the ease of use that it gives to use my favorite template toolkit,
TT, which is hugely featured.

But lately, I just discovered CGI::Application::Plugin::Redirect which makes
a single operation super easy, preserving a previously created session
(using CGI::Application::Plugin::Session) and headers to a new request on
the same system (different CGI, or different system completely) nicely.

What's yours?

-- 
David Moreno - http://www.damog.net/
Yes, you can.
From barry.moore at genetics.utah.edu  Wed Feb 13 23:07:49 2008
From: barry.moore at genetics.utah.edu (Barry Moore)
Date: Wed Feb 13 23:08:20 2008
Subject: [cgiapp] Program format (this is the way I write my code -help?)
In-Reply-To: <001601c86ea1$4a06aa80$6401a8c0@lousmaster>
References: <040e01c86975$02b18e60$06fe000a@gboffice.gorillabox.net><1202515011.27200.122.camel@zoe.savage.net.au><015101c86c95$4ee5f780$06fe000a@gboffice.gorillabox.net><1202807336.27200.145.camel@zoe.savage.net.au><00bf01c86e98$568d6310$0afe000a@gboffice.gorillabox.net><003001c86e9f$71735b60$6401a8c0@lousmaster>
	<45ba9f350802131629y74f5930fl54a41b489beee037@mail.gmail.com>
	<001601c86ea1$4a06aa80$6401a8c0@lousmaster>
Message-ID: <25D587CC-F41A-49BA-BB2F-39F9ED5AE16B@genetics.utah.edu>

Lou,

If your program was 10K lines long, then I'm guessing that there were  
a lot of different actions, and maybe a lot of html included in your  
code?  If you start to rewrite this with CGI::Application you might  
want to think about clustering those actions into smaller groups and  
making several smaller "applications" that work together as a suite  
for form your larger game.  For instance all of the actions  
associated with login could be one "application", while all of the  
actions associated with moving through the rooms in the dungeon (or  
whatever) could be associated with another "application".  This will  
break your code up into more manageable bits.

And if you have html strewn through your perl code, CGI::Application  
will make it easy for  you to adopt a html template language like  
HTML::Template or Template Toolkit which will get all of the html out  
of you code.  Google around for MVC frameworks and you'll see that  
CGI::Application and many other web application frameworks are trying  
to make it easy to separate the logic of your coding language (perl)  
from the presentation of you display language (html)  which makes  
your code more flexible and maintainable.

If you're being exposed to object oriented perl for the first time  
I'd recommend the first few chapters of the Object Oriented Perl book  
by Damain Conway (http://www.manning.com/conway/).

Barry

On Feb 13, 2008, at 5:33 PM, Lou Hernsen wrote:

> I sorta understand....and then not..
>
> The last program I wrote was 10K+ line long where I used only  
> subroutines
> all in one cgi....
> I was told I was nuts for doing that... now I am rewritting  
> everything over
> again... and using some
> new things I have learned about.... I will google some of the words  
> you used
> .. and see what i get.
>
> Is what your talking about called "object oriented"?
>
> thanks for the help...
> still lost but looking :)
> Lou
>
>
> ----- Original Message -----
> From: "Stewart Heckenberg" <stewart.heckenberg@gmail.com>
> To: "CGI Application" <cgiapp@lists.erlbaum.net>
> Sent: Wednesday, February 13, 2008 7:29 PM
> Subject: Re: [cgiapp] Program format (this is the way I write my
> code -help?)
>
>
>> Hi Lou,
>>
>> Actually you're close, but not close enough :)
>>
>> cgiapp actually allows you to get rid of all your if/else logic and
>> instead use what are called "run modes", which in terms of your games
>> are all the action/packets, e.g. instead of:
>>
>>  if ($Input{Action} eq "Log In")
>>
>> you would use:
>>
>> sub login {...
>>
>> and to trigger that sub to run, you set a query parameter called "rm"
>> to be "login", e.g. foo.cgi?rm=login
>>
>> That's how cgiapp works -- instead of if/else blocks for your logic,
>> you use subs, and to execute a particular sub you merely set the rm
>> param to be the name of that runmode/sub. Have a look at the cgiapp
>> documentation for some examples.
>>
>> Hope this helps :)
>>
>> Kind regards,
>> Stew
>>
>> On 14/02/2008, Lou Hernsen <lhernsen1015@wowway.com> wrote:
>>> Hallo
>>> I am writing an online game. I have a main .cgi and am using  
>>> packages
> which
>>> are "required" as needed.
>>> My .cgi is one long if-elsif-else all based on what action you  
>>> make in
> the
>>> game. I do it this way so I can complete one packet at a time to  
>>> do a
>>> certain thing.
>>> All files are read in the .cgi and vars passes to packages as
> needed..... am
>>> I even close in my method?
>>>
>>>>>>>> Mind you, this is a hobby to me.. all self taught....<<<<<<<
>>>
>>> ANY suggestion for books on program format would be helpfull..  
>>> thanks
>>> comments welcome.. try not to grind me into the dust, please LOL
>>> thanks
>>> Lou
>>>
>>> here is an example.
>>>
>>>  if ($Input{Action} eq "Log In")
>>>  {
>>>   $Pm{Status}=Login::LogIn("$Input{Name}","$Input{PW}");
>>>   exit;
>>>  }
>>>  elsif ($Input{Action} eq "New Player")
>>>  {
>>>   Login::NewPlayer();
>>>   exit;
>>>  }
>>>  elsif ($Input{Action} eq "Create Player")
>>>  {
>>>   Login::CreatePlayer("$Input{Name}","$Input{PW},"$Input{Gender}";
>>>   exit;
>>>  }
>>>  elsif ($Input{Action} eq "EmailLogin")
>>>  {
>>>   $Pm{Status}=Login::EmailLogin("$Input{Name}","$Input{SN}");
>>>   exit;
>>>  }
>>>
>>>
>>> #####  CGI::Application community mailing list  ################
>>> ##                                                            ##
>>> ##  To unsubscribe, or change your message delivery options,  ##
>>> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
>>> ##                                                            ##
>>> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
>>> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
>>> ##                                                            ##
>>> ################################################################
>>>
>>>
>>
>> #####  CGI::Application community mailing list  ################
>> ##                                                            ##
>> ##  To unsubscribe, or change your message delivery options,  ##
>> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
>> ##                                                            ##
>> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
>> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
>> ##                                                            ##
>> ################################################################
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.516 / Virus Database: 269.20.4/1275 - Release Date:  
>> 2/12/08
> 3:20 PM
>>
>>
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>

From mark at rawcane.net  Thu Feb 14 05:59:28 2008
From: mark at rawcane.net (Mark Knoop)
Date: Thu Feb 14 05:59:34 2008
Subject: [cgiapp] Lazy DBI
Message-ID: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net>

Hi

Still getting up to speed on CGI::Application while redeveloping my app 
along with your valuable help.

I am looking at the DBI plugin and would like to benefit from the lazy 
loading idea.

The thing is the actual database calls will be made from other objects.

So I can put dbh_config in cgiapp_init but then how do I best get the dbh 
when I need it?

I have been considering the various param options with your help via another 
thread and am still considering my options but however I do that I don't 
really want to be passing the CGI::Application into every new object just so 
I can get to the dbh.

But (I may be wrong) if I create a dbh ref to pass around then I create a 
connection and so lose out on the lazy loading.

Any advice on the best approach to this?

Thanks
Mark 

From unrtst at gmail.com  Thu Feb 14 06:27:51 2008
From: unrtst at gmail.com (Joshua Miller)
Date: Thu Feb 14 06:27:55 2008
Subject: [cgiapp] Lazy DBI
In-Reply-To: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net>
References: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net>
Message-ID: <1b9c12d0802140327q4c920a46q104e79fe85a13714@mail.gmail.com>

Just my 2cents... Apache::DBI. Entirely forget about passing it around..
that's too much work. Create an ini file or something, and put your
connection options in there, maybe even your own lib to connect to various
db's, but call the connect from various libs whenever needed, and let
Apache::DBI handle caching the connections. Apache::DBI is simply a more
elegant solution... only problem is that it assumes you're running apache
(not an problem for me).

On Thu, Feb 14, 2008 at 5:59 AM, Mark Knoop <mark@rawcane.net> wrote:

> Hi
>
> Still getting up to speed on CGI::Application while redeveloping my app
> along with your valuable help.
>
> I am looking at the DBI plugin and would like to benefit from the lazy
> loading idea.
>
> The thing is the actual database calls will be made from other objects.
>
> So I can put dbh_config in cgiapp_init but then how do I best get the dbh
> when I need it?
>
> I have been considering the various param options with your help via
> another
> thread and am still considering my options but however I do that I don't
> really want to be passing the CGI::Application into every new object just
> so
> I can get to the dbh.
>
> But (I may be wrong) if I create a dbh ref to pass around then I create a
> connection and so lose out on the lazy loading.
>
> Any advice on the best approach to this?
>
> Thanks
> Mark
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
From sdavis2 at mail.nih.gov  Thu Feb 14 06:31:17 2008
From: sdavis2 at mail.nih.gov (Sean Davis)
Date: Thu Feb 14 06:31:20 2008
Subject: [cgiapp] Lazy DBI
In-Reply-To: <1b9c12d0802140327q4c920a46q104e79fe85a13714@mail.gmail.com>
References: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net>
	<1b9c12d0802140327q4c920a46q104e79fe85a13714@mail.gmail.com>
Message-ID: <264855a00802140331n53269fa4ib01d5004bc8efa48@mail.gmail.com>

On Thu, Feb 14, 2008 at 6:27 AM, Joshua Miller <unrtst@gmail.com> wrote:
> Just my 2cents... Apache::DBI. Entirely forget about passing it around..
>  that's too much work. Create an ini file or something, and put your
>  connection options in there, maybe even your own lib to connect to various
>  db's, but call the connect from various libs whenever needed, and let
>  Apache::DBI handle caching the connections. Apache::DBI is simply a more
>  elegant solution... only problem is that it assumes you're running apache
>  (not an problem for me).

I was just starting an email that says the same thing.  It just works,
and no code changes need to be made (assuming you followed some pretty
basic guidelines).

Sean
From mark at rawcane.net  Thu Feb 14 07:03:34 2008
From: mark at rawcane.net (Mark Knoop)
Date: Thu Feb 14 07:03:40 2008
Subject: [cgiapp] Lazy DBI
References: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net><1b9c12d0802140327q4c920a46q104e79fe85a13714@mail.gmail.com>
	<264855a00802140331n53269fa4ib01d5004bc8efa48@mail.gmail.com>
Message-ID: <01f901c86f01$9fe255c0$0afe000a@gboffice.gorillabox.net>

> On Thu, Feb 14, 2008 at 6:27 AM, Joshua Miller <unrtst@gmail.com> wrote:
>> Just my 2cents... Apache::DBI. Entirely forget about passing it around..
>>  that's too much work. Create an ini file or something, and put your
>>  connection options in there, maybe even your own lib to connect to 
>> various
>>  db's, but call the connect from various libs whenever needed, and let
>>  Apache::DBI handle caching the connections. Apache::DBI is simply a more
>>  elegant solution... only problem is that it assumes you're running 
>> apache
>>  (not an problem for me).
>
> I was just starting an email that says the same thing.  It just works,
> and no code changes need to be made (assuming you followed some pretty
> basic guidelines).
>

Ah.... am using IIS as we are on Windoze and I am not as familiar with 
administering Apache (and we can't afford a sysadmin just yet). I am 
planning to migrate and go down the mod_perl route but that is down the list 
after CGI::Appifying my code and implementing some other essential 
features.... can only handle so much new stuff at once! Will bear your 
comments in mind for the future though. 

From peter at peknet.com  Thu Feb 14 09:33:01 2008
From: peter at peknet.com (Peter Karman)
Date: Thu Feb 14 09:33:03 2008
Subject: [cgiapp] Lazy DBI
In-Reply-To: <01f901c86f01$9fe255c0$0afe000a@gboffice.gorillabox.net>
References: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net><1b9c12d0802140327q4c920a46q104e79fe85a13714@mail.gmail.com>	<264855a00802140331n53269fa4ib01d5004bc8efa48@mail.gmail.com>
	<01f901c86f01$9fe255c0$0afe000a@gboffice.gorillabox.net>
Message-ID: <47B4511D.3090608@peknet.com>



On 02/14/2008 06:03 AM, Mark Knoop wrote:

> Ah.... am using IIS as we are on Windoze and I am not as familiar with
> administering Apache (and we can't afford a sysadmin just yet). I am
> planning to migrate and go down the mod_perl route but that is down the
> list after CGI::Appifying my code and implementing some other essential
> features.... can only handle so much new stuff at once! Will bear your
> comments in mind for the future though.
> 

consider something like Rose::DB then. It handles the persistent DBI connections, is
Apache/mod_perl-aware, and makes it easy to config your connections.

-- 
Peter Karman  .  peter@peknet.com  .  http://peknet.com/

From ron at savage.net.au  Thu Feb 14 18:17:24 2008
From: ron at savage.net.au (Ron Savage)
Date: Thu Feb 14 18:16:25 2008
Subject: [cgiapp] Poll: What's your favorite CGI-App plugin and why?
In-Reply-To: <144c024a0802131801i38274aacq509879645362ae38@mail.gmail.com>
References: <144c024a0802131801i38274aacq509879645362ae38@mail.gmail.com>
Message-ID: <1203031044.5177.9.camel@zoe.savage.net.au>

On Wed, 2008-02-13 at 21:01 -0500, David Moreno wrote:

Hi David

> I'd like to start a little poll about what are people's favorite CGI-App
> plugins and why.

CGI::Application::Dispatch
CGI::Application::Plugin::Session
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From brian at etcproject.com  Fri Feb 15 10:06:54 2008
From: brian at etcproject.com (Brian Edwards)
Date: Fri Feb 15 10:00:34 2008
Subject: [cgiapp] Poll: What's your favorite CGI-App plugin and why?
In-Reply-To: <1203031044.5177.9.camel@zoe.savage.net.au>
References: <144c024a0802131801i38274aacq509879645362ae38@mail.gmail.com>
	<1203031044.5177.9.camel@zoe.savage.net.au>
Message-ID: <200802150906.54633.brian@etcproject.com>

On Thursday 14 February 2008 17:17:24 Ron Savage wrote:
> On Wed, 2008-02-13 at 21:01 -0500, David Moreno wrote:
>
> Hi David
>
> > I'd like to start a little poll about what are people's favorite CGI-App
> > plugins and why.
>
> CGI::Application::Dispatch
> CGI::Application::Plugin::Session

Ditto, along with:

CGI::Application::Plugin::DBH
CGI::Application::Plugin::Redirect
CGI::Application::Plugin::ConfigAuto

Regarding CGI::Application::Plugin::DBH, I know it's a good practice to 
abstract the db logic from the app, but I'm using postgres custom variable 
classes by calling:
  $self->dbh->do("SET customclassname.variablename = ?", undef, 'foo')
and I switch the handle at times with:
  $self->dbh_default_name('dbh_handle_name').  

I need to do those things inside C::A, so I use the plugin.

BTW, can somebody tell me if I am correct in using:

use CGI::Session (qw/-ip_match/);
use CGI::Application::Plugin::Session;

to require the remote host ip address to match the ip stored in the session?

--
Brian Edwards
brian@etcproject.com


From breadwild at gmail.com  Fri Feb 15 11:17:30 2008
From: breadwild at gmail.com (Brad Cathey)
Date: Fri Feb 15 11:17:34 2008
Subject: [cgiapp] Anomaly in CAP::Session
Message-ID: <9c83f0330802150817w757e54ecp9bfa7e91cc105f70@mail.gmail.com>

I don't know if this has been discussed previously, but I can't kill a
session with:

      $self->session_delete;

however:

	my $session = new CGI::Session();
	$session->delete();

works like a champ.

Am I missing anything?

Thanks!
From lecar_red at yahoo.com  Fri Feb 15 15:00:46 2008
From: lecar_red at yahoo.com (Lee Carmichael)
Date: Fri Feb 15 15:00:49 2008
Subject: [cgiapp] Session name, CGI::Session and CAP::Session
Message-ID: <676767.78550.qm@web31415.mail.mud.yahoo.com>

Hello Everyone,

I am having a bit of an issue with how the 'name' attribute is being set on CGI::Session (CGI::Session->name). It is necessary to set the class value for 'name' before creating a session after which it is possible and useful to set it on the instance. 

I have a base class that I use for multiple CGI::App sub classes, this setups the main support for CAP::Session. Since we have lots of different cgi based apps that do very different things and that shouldn't really share session data, I need a way to alter this name. The main problem is that some of these apps are mod-perl based, which is where the class value causes issues ( or has the potential for issues). I know that I could use the 'path' value but there are cases where two subclasses could use the same session but be at different paths... ( I know, I'm being a pain in the butt :)

I have found a solution but I'm not sure its the best one. In the base class, I allow each class to set the name differently for each app as a parameter. The main problem I run into is to prevent issues with it storing that for all other sub classes, I need to do something like:

... in some code that is called as a init callback....

    ## fetch current global name
    my $old  = CGI::Session->name;

    ## change it temporarily until new session has been created
    CGI::Session->name( $self->session_name );
    $self->session->name( $self->session_name );

    ## restore global one 
    CGI::Session->name( $old);

This is pretty ugly but I couldn't figure out a way around it. This give me a brief amount of time where the package value is set and I hope that it doesn't get used (or reset) by another app. Most of the apps are used by just a few (or single) users so this isn't a huge problem. But it just doesn't feel right.

>From looking at the CGI::Session code, I don't there is another way to do this. Any ideas? 

One solution that I had was a new hash ref of parameters could be passed to 'new' and 'load' (of CGI::Session). Something like:

CGI::Session->new( 'driver:File', $self->query, { Directory  => File::Spec->tmpdir}, { name => 'SpecialName', update_atime => 1, .... } );

I am very willing to create a patch and tests for this new constructor option, if it makes sense to everyone.

Also, I have noticed that CAP::Session uses CGI::Session->name is a few places where the instance may have changed the parameter and will require a patch to fix these issues. I am willing to produce a patch and test for these issues as well.

Thanks, 

Lee






From bruce at 2MinuteExplainer.com  Fri Feb 15 16:51:56 2008
From: bruce at 2MinuteExplainer.com (Bruce McKenzie)
Date: Fri Feb 15 16:52:00 2008
Subject: [cgiapp] CGI::Application::Dispatch implementation
Message-ID: <47B6097C.9020304@2MinuteExplainer.com>

CGI::Application::Dispatch is a favorite plugin of many on this list, 
and it used to be one of mine, but it stopped working in my setup at 
version 2.x. Never figured out why, and I'm OK doing things the 
old-fashioned way, but I thought I'd give it another shot.

Suppose I have:

   directory cgi-bin/admin containing
     a webapp called "test.pl"
     a directory Modules,
           which contains Notify.pm
                which has a run mode "test"

I want to call the following under normal CGI
http://localhost/cgi-bin/admin/test.pl/notify/test

What is the simplest way to write the dispatch app? As I understand the 
documentation, this should do the right thing:

    #!/usr/bin/perl
    use strict;
    use FindBin qw($Bin);
    use lib "$Bin/Modules"; # add "Modules" dir to @INC just in case	
    use CGI::Application::Dispatch();

    CGI::Application::Dispatch->dispatch(prefix=>"Modules");


But, obviously, I don't understand the documentation, because, this, and 
every other attempt at it produces only a "Not Found" error.

thx,


-- 
Bruce McKenzie
Business Information Graphics

212-477-4288
http://www.2MinuteExplainer.com
From trwww at sbcglobal.net  Fri Feb 15 16:56:06 2008
From: trwww at sbcglobal.net (Todd Wade)
Date: Fri Feb 15 16:56:08 2008
Subject: [cgiapp] Session name, CGI::Session and CAP::Session
Message-ID: <971794.81700.qm@web82002.mail.mud.yahoo.com>

Hi Lee,

Unless I'm misunderstanding I would dispense with CAP::Session and store different CGI::Session instances in CAP::Stash:

http://search.cpan.org/~kazeburo/CGI-Application-Plugin-Stash/lib/CGI/Application/Plugin/Stash.pm

use CGI::Application::Plugin::Stash;
...
$self->stash->{sessions}{'My::Subclass1'} = CGI::Session->new(...);
$self->stash->{sessions}{'My::Subclass2'} = CGI::Session->new(...);

Then maybe make my own ->session method that finds the correct session for the subclass:

sub session {
  my $self = shift;
  return $self->stash->{sessions}{ ref $self };
}

?

Todd W.

----- Original Message ----
From: Lee Carmichael <lecar_red@yahoo.com>
To: cgiapp@lists.erlbaum.net
Sent: Friday, February 15, 2008 3:00:46 PM
Subject: [cgiapp] Session name, CGI::Session and CAP::Session

Hello Everyone,

I am having a bit of an issue with how the 'name' attribute is being set on CGI::Session (CGI::Session->name). It is necessary to set the class value for 'name' before creating a session after which it is possible and useful to set it on the instance. 

I have a base class that I use for multiple CGI::App sub classes, this setups the main support for CAP::Session. Since we have lots of different cgi based apps that do very different things and that shouldn't really share session data, I need a way to alter this name. The main problem is that some of these apps are mod-perl based, which is where the class value causes issues ( or has the potential for issues). I know that I could use the 'path' value but there are cases where two subclasses could use the same session but be at different paths... ( I know, I'm being a pain in the butt :)

I have found a solution but I'm not sure its the best one. In the base class, I allow each class to set the name differently for each app as a parameter. The main problem I run into is to prevent issues with it storing that for all other sub classes, I need to do something like:

... in some code that is called as a init callback....

    ## fetch current global name
    my $old  = CGI::Session->name;

    ## change it temporarily until new session has been created
    CGI::Session->name( $self->session_name );
    $self->session->name( $self->session_name );

    ## restore global one 
    CGI::Session->name( $old);

This is pretty ugly but I couldn't figure out a way around it. This give me a brief amount of time where the package value is set and I hope that it doesn't get used (or reset) by another app. Most of the apps are used by just a few (or single) users so this isn't a huge problem. But it just doesn't feel right.

>From looking at the CGI::Session code, I don't there is another way to do this. Any ideas? 

One solution that I had was a new hash ref of parameters could be passed to 'new' and 'load' (of CGI::Session). Something like:

CGI::Session->new( 'driver:File', $self->query, { Directory  => File::Spec->tmpdir}, { name => 'SpecialName', update_atime => 1, .... } );

I am very willing to create a patch and tests for this new constructor option, if it makes sense to everyone.

Also, I have noticed that CAP::Session uses CGI::Session->name is a few places where the instance may have changed the parameter and will require a patch to fix these issues. I am willing to produce a patch and test for these issues as well.

Thanks, 

Lee







#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:  http://www.erlbaum.net/pipermail/cgiapp/  ##
##  Wiki:          http://cgiapp.erlbaum.net/                ##
##                                                            ##
################################################################
From mpeters at plusthree.com  Fri Feb 15 17:00:40 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Fri Feb 15 17:02:55 2008
Subject: [cgiapp] CGI::Application::Dispatch implementation
In-Reply-To: <47B6097C.9020304@2MinuteExplainer.com>
References: <47B6097C.9020304@2MinuteExplainer.com>
Message-ID: <47B60B88.30008@plusthree.com>

Bruce McKenzie wrote:
> CGI::Application::Dispatch is a favorite plugin of many on this list,
> and it used to be one of mine, but it stopped working in my setup at
> version 2.x. Never figured out why, and I'm OK doing things the
> old-fashioned way, but I thought I'd give it another shot.
> 
> Suppose I have:
> 
>   directory cgi-bin/admin containing
>     a webapp called "test.pl"
>     a directory Modules,

Btw, this is normally called "lib" and not "Modules" for most Perl projects.

>           which contains Notify.pm
>                which has a run mode "test"
> 
> I want to call the following under normal CGI
> http://localhost/cgi-bin/admin/test.pl/notify/test
> 
> What is the simplest way to write the dispatch app? As I understand the
> documentation, this should do the right thing:
> 
>    #!/usr/bin/perl
>    use strict;
>    use FindBin qw($Bin);
>    use lib "$Bin/Modules"; # add "Modules" dir to @INC just in case   
>    use CGI::Application::Dispatch();
> 
>    CGI::Application::Dispatch->dispatch(prefix=>"Modules");

Is your module's package called "Modules::Notify" or just "Notify"? If it's the
first then change your "use lib" line to:

  use lib $Bin;

If it's the latter, then you don't need a prefix at all:

  CGI::Application::Dispatch->dispatch();

> But, obviously, I don't understand the documentation, because, this, and
> every other attempt at it produces only a "Not Found" error.

You can turn on debugging to see how things are getting translated by putting
debug => 1 into your call to dispatch(). But it basically works like this (using
your example url test.pl/notify/test):

1) look at the first part of the path, "notify", and run it through
translate_module_name() so that it becomes "Notify"
2) Add any defined prefix so that it becomes "Modules::Notify".
3) Modules::Notify is "require"d which means Perl will look in @INC for a file
named Modules/Notify.pm and that has a package name of Modules::Notify.

-- 
Michael Peters
Plus Three, LP

From lecar_red at yahoo.com  Fri Feb 15 17:33:25 2008
From: lecar_red at yahoo.com (Lee Carmichael)
Date: Fri Feb 15 17:33:27 2008
Subject: [cgiapp] Session name, CGI::Session and CAP::Session
Message-ID: <477619.98324.qm@web31404.mail.mud.yahoo.com>

Hello Todd,

Good to hear from you.

I think I might not have been clear. I do want the sessions to be manage per user but I want to alter the session name in the cookie/url based upon the application subclass.

e.g.

App::Base has subclasses:

   App::A - has session name of 'A' 
   App::B - has session name of 'B'
   App::C and App::D - share some settings/values between them and share session name of 'CD'.

Thanks for pointing out the Stash module, I didn't know there was one for CGI app and that is very useful for lots of things.

Take Care,

Lee

----- Original Message ----
From: Todd Wade <trwww@sbcglobal.net>
To: CGI Application <cgiapp@lists.erlbaum.net>
Sent: Friday, February 15, 2008 3:56:06 PM
Subject: Re: [cgiapp] Session name, CGI::Session and CAP::Session

Hi Lee,

Unless I'm misunderstanding I would dispense with CAP::Session and store different CGI::Session instances in CAP::Stash:

http://search.cpan.org/~kazeburo/CGI-Application-Plugin-Stash/lib/CGI/Application/Plugin/Stash.pm

use CGI::Application::Plugin::Stash;
...
$self->stash->{sessions}{'My::Subclass1'} = CGI::Session->new(...);
$self->stash->{sessions}{'My::Subclass2'} = CGI::Session->new(...);

Then maybe make my own ->session method that finds the correct session for the subclass:

sub session {
  my $self = shift;
  return $self->stash->{sessions}{ ref $self };
}

?

Todd W.

----- Original Message ----
From: Lee Carmichael <lecar_red@yahoo.com>
To: cgiapp@lists.erlbaum.net
Sent: Friday, February 15, 2008 3:00:46 PM
Subject: [cgiapp] Session name, CGI::Session and CAP::Session

Hello Everyone,

I am having a bit of an issue with how the 'name' attribute is being set on CGI::Session (CGI::Session->name). It is necessary to set the class value for 'name' before creating a session after which it is possible and useful to set it on the instance. 

I have a base class that I use for multiple CGI::App sub classes, this setups the main support for CAP::Session. Since we have lots of different cgi based apps that do very different things and that shouldn't really share session data, I need a way to alter this name. The main problem is that some of these apps are mod-perl based, which is where the class value causes issues ( or has the potential for issues). I know that I could use the 'path' value but there are cases where two subclasses could use the same session but be at different paths... ( I know, I'm being a pain in the butt :)

I have found a solution but I'm not sure its the best one. In the base class, I allow each class to set the name differently for each app as a parameter. The main problem I run into is to prevent issues with it storing that for all other sub classes, I need to do something like:

... in some code that is called as a init callback....

    ## fetch current global name
    my $old  = CGI::Session->name;

    ## change it temporarily until new session has been created
    CGI::Session->name( $self->session_name );
    $self->session->name( $self->session_name );

    ## restore global one 
    CGI::Session->name( $old);

This is pretty ugly but I couldn't figure out a way around it. This give me a brief amount of time where the package value is set and I hope that it doesn't get used (or reset) by another app. Most of the apps are used by just a few (or single) users so this isn't a huge problem. But it just doesn't feel right.

>From looking at the CGI::Session code, I don't there is another way to do this. Any ideas? 

One solution that I had was a new hash ref of parameters could be passed to 'new' and 'load' (of CGI::Session). Something like:

CGI::Session->new( 'driver:File', $self->query, { Directory  => File::Spec->tmpdir}, { name => 'SpecialName', update_atime => 1, .... } );

I am very willing to create a patch and tests for this new constructor option, if it makes sense to everyone.

Also, I have noticed that CAP::Session uses CGI::Session->name is a few places where the instance may have changed the parameter and will require a patch to fix these issues. I am willing to produce a patch and test for these issues as well.

Thanks, 

Lee







#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:  http://www.erlbaum.net/pipermail/cgiapp/  ##
##  Wiki:          http://cgiapp.erlbaum.net/                ##
##                                                            ##
################################################################

#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################




From mpeters at plusthree.com  Fri Feb 15 17:38:31 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Fri Feb 15 17:40:52 2008
Subject: [cgiapp] Session name, CGI::Session and CAP::Session
In-Reply-To: <477619.98324.qm@web31404.mail.mud.yahoo.com>
References: <477619.98324.qm@web31404.mail.mud.yahoo.com>
Message-ID: <47B61467.6070306@plusthree.com>

Lee Carmichael wrote:

> I think I might not have been clear. I do want the sessions to be manage per user but I want to alter the session name in the cookie/url based upon the application subclass.

Are you sure you want separate sessions? Or do you just want different locations
in the same session? Will these separate sessions have different expiration
values? Or do you just want to put different things into different "buckets"?

If you do want different sessions then I don't think C::A::P::Session will work
(I could be wrong). If you just want different buckets, then just treat your
session hash as a multi-level hash.

  my $a_session = $self->session->param('A');
  $a_session->{foo} = 'blah';
  my $b_session = $self->session->param('B');
  $b_session->{foo} = 'baz';

-- 
Michael Peters
Plus Three, LP

From trwww at sbcglobal.net  Fri Feb 15 17:51:21 2008
From: trwww at sbcglobal.net (Todd Wade)
Date: Fri Feb 15 17:51:22 2008
Subject: [cgiapp] Session name, CGI::Session and CAP::Session
Message-ID: <704020.28466.qm@web82005.mail.mud.yahoo.com>

Ah... it seems like you should be able to call ->session_config with the right settings "in some code that is called as a init callback", no?

http://search.cpan.org/~ceeshek/CGI-Application-Plugin-Session-0.09/lib/CGI/Application/Plugin/Session.pm#session_config

Because of lazy loading, as long as nothing accesses the session before the init callback is called, you should be good to go.

After your call to ->session_config, all calls to ->session for the rest of the request will use the cookie you specified.

Todd W.

----- Original Message ----
From: Lee Carmichael <lecar_red@yahoo.com>
To: CGI Application <cgiapp@lists.erlbaum.net>
Sent: Friday, February 15, 2008 5:33:25 PM
Subject: Re: [cgiapp] Session name, CGI::Session and CAP::Session

Hello Todd,

Good to hear from you.

I think I might not have been clear. I do want the sessions to be manage per user but I want to alter the session name in the cookie/url based upon the application subclass.

e.g.

App::Base has subclasses:

  App::A - has session name of 'A' 
  App::B - has session name of 'B'
  App::C and App::D - share some settings/values between them and share session name of 'CD'.

Thanks for pointing out the Stash module, I didn't know there was one for CGI app and that is very useful for lots of things.

Take Care,

Lee

----- Original Message ----
From: Todd Wade <trwww@sbcglobal.net>
To: CGI Application <cgiapp@lists.erlbaum.net>
Sent: Friday, February 15, 2008 3:56:06 PM
Subject: Re: [cgiapp] Session name, CGI::Session and CAP::Session

Hi Lee,

Unless I'm misunderstanding I would dispense with CAP::Session and store different CGI::Session instances in CAP::Stash:

http://search.cpan.org/~kazeburo/CGI-Application-Plugin-Stash/lib/CGI/Application/Plugin/Stash.pm

use CGI::Application::Plugin::Stash;
...
$self->stash->{sessions}{'My::Subclass1'} = CGI::Session->new(...);
$self->stash->{sessions}{'My::Subclass2'} = CGI::Session->new(...);

Then maybe make my own ->session method that finds the correct session for the subclass:

sub session {
  my $self = shift;
  return $self->stash->{sessions}{ ref $self };
}

?

Todd W.

----- Original Message ----
From: Lee Carmichael <lecar_red@yahoo.com>
To: cgiapp@lists.erlbaum.net
Sent: Friday, February 15, 2008 3:00:46 PM
Subject: [cgiapp] Session name, CGI::Session and CAP::Session

Hello Everyone,

I am having a bit of an issue with how the 'name' attribute is being set on CGI::Session (CGI::Session->name). It is necessary to set the class value for 'name' before creating a session after which it is possible and useful to set it on the instance. 

I have a base class that I use for multiple CGI::App sub classes, this setups the main support for CAP::Session. Since we have lots of different cgi based apps that do very different things and that shouldn't really share session data, I need a way to alter this name. The main problem is that some of these apps are mod-perl based, which is where the class value causes issues ( or has the potential for issues). I know that I could use the 'path' value but there are cases where two subclasses could use the same session but be at different paths... ( I know, I'm being a pain in the butt :)

I have found a solution but I'm not sure its the best one. In the base class, I allow each class to set the name differently for each app as a parameter. The main problem I run into is to prevent issues with it storing that for all other sub classes, I need to do something like:

... in some code that is called as a init callback....

    ## fetch current global name
    my $old  = CGI::Session->name;

    ## change it temporarily until new session has been created
    CGI::Session->name( $self->session_name );
    $self->session->name( $self->session_name );

    ## restore global one 
    CGI::Session->name( $old);

This is pretty ugly but I couldn't figure out a way around it. This give me a brief amount of time where the package value is set and I hope that it doesn't get used (or reset) by another app. Most of the apps are used by just a few (or single) users so this isn't a huge problem. But it just doesn't feel right.

>From looking at the CGI::Session code, I don't there is another way to do this. Any ideas? 

One solution that I had was a new hash ref of parameters could be passed to 'new' and 'load' (of CGI::Session). Something like:

CGI::Session->new( 'driver:File', $self->query, { Directory  => File::Spec->tmpdir}, { name => 'SpecialName', update_atime => 1, .... } );

I am very willing to create a patch and tests for this new constructor option, if it makes sense to everyone.

Also, I have noticed that CAP::Session uses CGI::Session->name is a few places where the instance may have changed the parameter and will require a patch to fix these issues. I am willing to produce a patch and test for these issues as well.

Thanks, 

Lee







#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:  http://www.erlbaum.net/pipermail/cgiapp/  ##
##  Wiki:          http://cgiapp.erlbaum.net/                ##
##                                                            ##
################################################################

#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:  http://www.erlbaum.net/pipermail/cgiapp/  ##
##  Wiki:          http://cgiapp.erlbaum.net/                ##
##                                                            ##
################################################################





#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:  http://www.erlbaum.net/pipermail/cgiapp/  ##
##  Wiki:          http://cgiapp.erlbaum.net/                ##
##                                                            ##
################################################################
From ceeshek at gmail.com  Fri Feb 15 17:58:27 2008
From: ceeshek at gmail.com (Cees Hek)
Date: Fri Feb 15 17:58:31 2008
Subject: [cgiapp] Poll: What's your favorite CGI-App plugin and why?
In-Reply-To: <200802150906.54633.brian@etcproject.com>
References: <144c024a0802131801i38274aacq509879645362ae38@mail.gmail.com>
	<1203031044.5177.9.camel@zoe.savage.net.au>
	<200802150906.54633.brian@etcproject.com>
Message-ID: <fd8e28ef0802151458u5e17d25fud9e21c1e7de128a5@mail.gmail.com>

On Sat, Feb 16, 2008 at 2:06 AM, Brian Edwards <brian@etcproject.com> wrote:
>  BTW, can somebody tell me if I am correct in using:
>
>  use CGI::Session (qw/-ip_match/);
>  use CGI::Application::Plugin::Session;
>
>  to require the remote host ip address to match the ip stored in the session?

Yes, that should work.  There are a couple of things to consider when
using this though.

First, if you are running under mod_perl or some other persistent
environment, then all your apps will use the -ip_match switch as soon
as it is loaded in one of them.  This is because it is implemented
using a global variable in the CGI::Session namespace.

Second, there are some clients out there that may come from different
IP addresses on every request if they are using a pool of proxy
servers.  So make sure you know your audience when using this option.

Cheers,

Cees
From mpeters at plusthree.com  Fri Feb 15 18:02:09 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Fri Feb 15 18:04:24 2008
Subject: [cgiapp] Poll: What's your favorite CGI-App plugin and why?
In-Reply-To: <fd8e28ef0802151458u5e17d25fud9e21c1e7de128a5@mail.gmail.com>
References: <144c024a0802131801i38274aacq509879645362ae38@mail.gmail.com>	<1203031044.5177.9.camel@zoe.savage.net.au>	<200802150906.54633.brian@etcproject.com>
	<fd8e28ef0802151458u5e17d25fud9e21c1e7de128a5@mail.gmail.com>
Message-ID: <47B619F1.6040907@plusthree.com>

Cees Hek wrote:

> Second, there are some clients out there that may come from different
> IP addresses on every request if they are using a pool of proxy
> servers.  So make sure you know your audience when using this option.

This is especially true for something like the iphone or other wireless internet
devices. If your user is moving, even just walking sometimes, they can switch
the proxy server they will be coming from. Which means they will be logged out.

Third, if you ever have to scale your application so that's it's behind a
reverse proxy (a very typical first stage when scaling) everything will break
since everyone will appear to be coming from the same IP.

-- 
Michael Peters
Plus Three, LP

From ceeshek at gmail.com  Fri Feb 15 18:11:20 2008
From: ceeshek at gmail.com (Cees Hek)
Date: Fri Feb 15 18:11:24 2008
Subject: [cgiapp] Anomaly in CAP::Session
In-Reply-To: <9c83f0330802150817w757e54ecp9bfa7e91cc105f70@mail.gmail.com>
References: <9c83f0330802150817w757e54ecp9bfa7e91cc105f70@mail.gmail.com>
Message-ID: <fd8e28ef0802151511g6c39949el3c402441609da81c@mail.gmail.com>

On Sat, Feb 16, 2008 at 3:17 AM, Brad Cathey <breadwild@gmail.com> wrote:
> I don't know if this has been discussed previously, but I can't kill a
>  session with:
>
>       $self->session_delete;
>
>  however:
>
>         my $session = new CGI::Session();
>         $session->delete();
>
>  works like a champ.
>
>  Am I missing anything?

That is odd, since if you look at the source you will see that the
first thing that a call to session_delete does is call ->delete on the
session object.  The rest of it is just dealing with cookies.

How are you checking to see if the session is deleted?  If you call
$self->session again as a test to see if it was deleted, then that
will just create a brand new session for you.  You need to look in the
session store to see if the session was deleted or not.

If you are sure it is a problem, then I will need to see a self
contained example that shows the problem before I can go any further
(preferably using the test suite).

Cheers,

Cees
From perrin at elem.com  Fri Feb 15 18:12:00 2008
From: perrin at elem.com (Perrin Harkins)
Date: Fri Feb 15 18:12:02 2008
Subject: [cgiapp] Poll: What's your favorite CGI-App plugin and why?
In-Reply-To: <144c024a0802131801i38274aacq509879645362ae38@mail.gmail.com>
References: <144c024a0802131801i38274aacq509879645362ae38@mail.gmail.com>
Message-ID: <66887a3d0802151512y4ad88186n7245505c59793171@mail.gmail.com>

On Feb 13, 2008 9:01 PM, David Moreno <david@espiral.org.mx> wrote:
> I'd like to start a little poll about what are people's favorite CGI-App
> plugins and why.

CGI::Application::Plugin::ValidateRM is wicked awesome for tying up a
common application pattern into a neat bundle.

- Perrin
From ceeshek at gmail.com  Fri Feb 15 18:31:44 2008
From: ceeshek at gmail.com (Cees Hek)
Date: Fri Feb 15 18:31:48 2008
Subject: [cgiapp] Poll: What's your favorite CGI-App plugin and why?
In-Reply-To: <47B619F1.6040907@plusthree.com>
References: <144c024a0802131801i38274aacq509879645362ae38@mail.gmail.com>
	<1203031044.5177.9.camel@zoe.savage.net.au>
	<200802150906.54633.brian@etcproject.com>
	<fd8e28ef0802151458u5e17d25fud9e21c1e7de128a5@mail.gmail.com>
	<47B619F1.6040907@plusthree.com>
Message-ID: <fd8e28ef0802151531g1dc7ce2foa9a1760a4c833cb0@mail.gmail.com>

On Sat, Feb 16, 2008 at 10:02 AM, Michael Peters <mpeters@plusthree.com> wrote:
>  Third, if you ever have to scale your application so that's it's behind a
>  reverse proxy (a very typical first stage when scaling) everything will break
>  since everyone will appear to be coming from the same IP.

For an apache solution to this problem, you can use mod_rpaf to solve
the issue.  Your proxy servers should be adding a Forwarded-For header
with the IP address of the originating requester.  If you run mod_rpaf
on the servers behind the proxies, and tell it about all your proxy
servers, then it will tell apache what the real originating address
is, and all your apps will see that value.

Cheers,

Cees
From bruce at 2MinuteExplainer.com  Fri Feb 15 18:34:17 2008
From: bruce at 2MinuteExplainer.com (Bruce McKenzie)
Date: Fri Feb 15 18:34:19 2008
Subject: [cgiapp] CGI::Application::Dispatch implementation
In-Reply-To: <47B60B88.30008@plusthree.com>
References: <47B6097C.9020304@2MinuteExplainer.com>
	<47B60B88.30008@plusthree.com>
Message-ID: <47B62179.7090109@2MinuteExplainer.com>

Michael Peters wrote in an email message dated 2/15/2008 5:00 PM:
> Is your module's package called "Modules::Notify" or just "Notify"? If it's the
> first then change your "use lib" line to:
> 
>   use lib $Bin;
> 
> If it's the latter, then you don't need a prefix at all:
> 
>   CGI::Application::Dispatch->dispatch();
> 

Thanks Michael. Any way I name it, I get a Not Found.

I tried this:
   #!/usr/bin/perl
   use strict;
   use FindBin qw($Bin);
   use lib "$Bin/../perl_lib"; # my standard lib
   use lib "$Bin/Modules"; # lib for this webapp
   use CGI::Application::Dispatch;
...
   my $name = CGI::Application::Dispatch->translate_module_name();
   print ($name || "No name found"); # prints "No name found"
   CGI::Application::Dispatch->dispatch(debug=>1) ; #Not Found

FWIW, this works as expected:

   #!/usr/bin/perl
   use strict;
   use FindBin qw($Bin);
   use lib "$Bin/../perl_lib";  # my standard lib
   use lib "$Bin/Modules"; # lib for this webapp

   use Notify;
   Notify->new->run(); #default runmode is 'test'



-- 
Bruce McKenzie

http://www.2MinuteExplainer.com
From jesse at erlbaum.net  Fri Feb 15 18:37:16 2008
From: jesse at erlbaum.net (Jesse Erlbaum)
Date: Fri Feb 15 18:38:38 2008
Subject: [cgiapp] [ANNOUNCE] Krang V3.01
Message-ID: <F3690AC81E5390499D4723777E499F9904BADD5B@34093-EVS1C1.exchange.rackspace.com>

Krang v3.01 Release: February 15, 2008


Release Summary

This release adds many new, and often requested features. Krang now supports multiple windows, permitting users to edit more than one story at a time. A syntax-highlighting text editor has been added for editing templates and text-based media (CSS, Javascript, HTML, XML, etc.). Numerous small bugs have been fixed, and performance enhanced. Significant improvements have been made to Krang's UTF-8 (Unicode) support. Major changes in this release include:

  * Multiple Krang window support.  Edit more than one story at once!
  * Syntax highlighting for template editing.
  * Online editing of text media (e.g.: CSS, Javascript, HTML, text, XML, etc.)
  * Previewing a story now respects edited form fields -- no more endless 
    "save & stay + preview"
  * When editing media, made "Save" and "Save & Stay" buttons automatically 
    publish to preview.
  * Added ability to replace one story with another in one step.
  * Improved UTF-8 support.
  * Fixed numerous bugs and improved overall performance.


About Krang

Krang is an open source web publishing/content management system, particularly well suited for high volume magazine-style web sites.  Originally developed in 2003 by Primedia, Krang is currently used by hundreds of well-known web sites including New York Magazine, Motor Trend, Soap Opera Digest, In-Fisherman, Guns & Ammo, Florida Sportsman, Game & Fish, Equisearch.com, Power & Motor Yacht, and many more.

Krang provides a powerful and easy to use story and media editing environment for website editors, as well as a complete template development environment for web designers. On the back-end, Perl programmers can customize Krang to control the data entered in the story editor and add code to drive the templates to build output. Krang can be enhanced with add-ons containing new skins and other new features. Krang easily handles large data sets and can manage multiple websites in a single installation.


Krang Links

Krang CMS web site: 
  http://www.krangcms.com

Full change log:
  http://www.krangcms.com/docs/changelog.html#3_01__february_1__2008

Download from SourceForge: 
  http://sourceforge.net/project/showfiles.php?group_id=103045

Mailing lists:
  http://lists.sourceforge.net/mailman/listinfo/krang-devel
  http://lists.sourceforge.net/mailman/listinfo/krang-general

Bug Tracker: 
  http://bugzilla.krangcms.com



?
Jesse Erlbaum
The Erlbaum Group, LLC
817 Broadway, 10th floor
New York, NY 10003
http://erlbaum.net
jesse@erlbaum.net


From mpeters at plusthree.com  Fri Feb 15 18:37:19 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Fri Feb 15 18:39:34 2008
Subject: [cgiapp] CGI::Application::Dispatch implementation
In-Reply-To: <47B62179.7090109@2MinuteExplainer.com>
References: <47B6097C.9020304@2MinuteExplainer.com>	<47B60B88.30008@plusthree.com>
	<47B62179.7090109@2MinuteExplainer.com>
Message-ID: <47B6222F.4080804@plusthree.com>

Bruce McKenzie wrote:

> Thanks Michael. Any way I name it, I get a Not Found.

That's becuase you didn't follow my advice :) See below.

> I tried this:
>   #!/usr/bin/perl
>   use strict;
>   use FindBin qw($Bin);
>   use lib "$Bin/../perl_lib"; # my standard lib
>   use lib "$Bin/Modules"; # lib for this webapp
>   use CGI::Application::Dispatch;
> ...
>   my $name = CGI::Application::Dispatch->translate_module_name();

translate_module_name() can't be called by itself. It needs arguments. It's not
meant to be called in your code. The only reason it's documented is so that you
can override it if you want.

>   print ($name || "No name found"); # prints "No name found"
>   CGI::Application::Dispatch->dispatch(debug=>1) ; #Not Found
> 
> FWIW, this works as expected:
> 
>   #!/usr/bin/perl
>   use strict;
>   use FindBin qw($Bin);
>   use lib "$Bin/../perl_lib";  # my standard lib
>   use lib "$Bin/Modules"; # lib for this webapp
> 
>   use Notify;
>   Notify->new->run(); #default runmode is 'test'

So your module is called 'Notify'. If you notice in my last email I said that if
it was called 'Notify' and not 'Modules::Notify' then you didn't need a prefix.
The prefix is tacked on to the beginning of the module name.

-- 
Michael Peters
Plus Three, LP

From bruce at 2MinuteExplainer.com  Fri Feb 15 18:56:00 2008
From: bruce at 2MinuteExplainer.com (Bruce McKenzie)
Date: Fri Feb 15 18:56:03 2008
Subject: [cgiapp] CGI::Application::Dispatch implementation
In-Reply-To: <47B6222F.4080804@plusthree.com>
References: <47B6097C.9020304@2MinuteExplainer.com>	<47B60B88.30008@plusthree.com>	<47B62179.7090109@2MinuteExplainer.com>
	<47B6222F.4080804@plusthree.com>
Message-ID: <47B62690.5090803@2MinuteExplainer.com>

Michael Peters wrote in an email message dated 2/15/2008 6:37 PM:
> Bruce McKenzie wrote:
> 
>> Thanks Michael. Any way I name it, I get a Not Found.
> 
> That's becuase you didn't follow my advice :) See below.
Well, I tried :-(
> 
> So your module is called 'Notify'. If you notice in my last email I said that if
> it was called 'Notify' and not 'Modules::Notify' then you didn't need a prefix.
> The prefix is tacked on to the beginning of the module name.
> 

Hmmm. Suddenly, it started working :-) No wonder people like this 
plugin. Thanks.

Cheers

Bruce
-- 
Bruce McKenzie
http://www.2MinuteExplainer.com
From bruce at 2MinuteExplainer.com  Sun Feb 17 17:20:52 2008
From: bruce at 2MinuteExplainer.com (Bruce McKenzie)
Date: Sun Feb 17 17:20:54 2008
Subject: [cgiapp] CGI Application::Dispatch and FatalsToBrowser
Message-ID: <47B8B344.5040104@2MinuteExplainer.com>

Hello,

I'm not having any luck getting errors to display in the browser when 
web applications are dispatched with CGI::App::Dispatch.

According to the way I read the documentation, this should send the 
error to the browser if there's an  error in the application:

CGI::Application::Dispatch->dispatch(
    default => "test/test",
    debug   => 1,
    # return in browser 'Opss... HTTP Error #404'
    error_document => '"Opss... HTTP Error #%s'

) ;

But it doesn't. It just shows Internal Server Error or Not Found. My 
development environment is WinXP, Apache2, normal CGI;

Thx,

Bruce


-- 
Bruce McKenzie
http://www.2MinuteExplainer.com
From azfuller at gmail.com  Mon Feb 18 15:00:12 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Mon Feb 18 15:00:18 2008
Subject: [cgiapp] Proposed plug-in (need help with name)
Message-ID: <d69cc4a60802181200k3e2f720ehf1c501fa50bae432@mail.gmail.com>

I'm preparing to upload a plugin to CPAN. (My first. I'm waiting for a
PAUSE password). I'd like to make sure others agree with how I name
it.

Summary:
=======

The module mimics Catalyst's behavior: When you return from a
controller action (runmode in C::A) it automatically renders your H::T
template (using a "stashed" template and vars). I was inspired to do
this when I saw plugin::Stash. It reminded me of the other neat thing
about Catalyst (automatically template handling).

It's extremely trivial. But, it might be useful if someone doesn't
want to interact directly with the template, and/or just wants
Catalyst-like behavior. They just stash their vars and template, and
return from their runmode. The plugin registers a callback to C::A's
"postrun" and gets an empty bodyref. It retrieves the template, and
for all the params found in the template, it attempts to set them if a
corresponding param is found in C::A (when the user "stashed" it). It
detects that a redirect is occurring, and avoids processing in that
case.

Question:
=======

My question is: What should it be named? Corresponding to the Catalyst
module that performs the same behavior, it would be named
CGI::Application::Plugin::View::HTML::Template.

Does anyone see anything wrong with that name? Or, think of a better name?

Thanks,
Mark
From mark at rawcane.net  Tue Feb 19 05:02:13 2008
From: mark at rawcane.net (Mark Knoop)
Date: Tue Feb 19 05:02:20 2008
Subject: [cgiapp] Lazy DBI
References: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net><1b9c12d0802140327q4c920a46q104e79fe85a13714@mail.gmail.com>	<264855a00802140331n53269fa4ib01d5004bc8efa48@mail.gmail.com><01f901c86f01$9fe255c0$0afe000a@gboffice.gorillabox.net>
	<47B4511D.3090608@peknet.com>
Message-ID: <00e001c872de$80951820$06fe000a@gboffice.gorillabox.net>

In case it is of interest I have solved the problem like this.

package GSystem::Common::DBH;

use strict;
use warnings;
use Log::Log4perl qw(get_logger);
use DBI;

our $dbh = undef;

sub dbh {

 my $log = get_logger('GSystem::Common::DBH');

 my $dbusr = "user";
 my $dbpwd = "pwd";
 my $dsn = "GSystem";

 $dbh = DBI->connect("DBI:ODBC:$dsn", $dbusr, $dbpwd, {RaiseError => 0, 
PrintError => 0})  || $log->logdie ("Could not connect to database")
  unless defined $dbh;

    return $dbh;
}

1;

So when I want a dbh I use

my $dbh = GSystem::Common::DBH::dbh;

and I (think) I either get a new or existing dbh.

I would be interested to know of any flaws in my logic...

Mark


From azfuller at gmail.com  Tue Feb 19 11:24:19 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Tue Feb 19 11:24:22 2008
Subject: [cgiapp] Lazy DBI
In-Reply-To: <00e001c872de$80951820$06fe000a@gboffice.gorillabox.net>
References: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net>
	<1b9c12d0802140327q4c920a46q104e79fe85a13714@mail.gmail.com>
	<264855a00802140331n53269fa4ib01d5004bc8efa48@mail.gmail.com>
	<01f901c86f01$9fe255c0$0afe000a@gboffice.gorillabox.net>
	<47B4511D.3090608@peknet.com>
	<00e001c872de$80951820$06fe000a@gboffice.gorillabox.net>
Message-ID: <d69cc4a60802190824o251ffe5dl23e1254cd6689059@mail.gmail.com>

> I would be interested to know of any flaws in my logic...

I did something like that, but went further. I started out with the
goal not to connect to the DB until necessary, and ended up with a
goal not to even test if I've already connected to the DB, or if the
handle is still alive, etc. I didn't want to have all those "if
(!$dbh) { connect }" or those DBI "pings" before every operation.

I reversed the logic so that it uses my module to execute prepared
statement handles within an eval. If it fails, it disconnects,
reconnects, and tries to execute the prepared statement handle again
(up to n times). So, the idea is, I default to just processing as if
I'm always connected to the DB. I let this DB handler catch errors,
retry connections and executions, etc.

I went one step further and let it "lazy prepare" statement handles
too. If the eval'ed execution fails, my logic determines the statement
isn't prepared. It prepares it, and then does the retry.

So, I just process without getting pedantic about "have I connected to
the DB yet?" "Did I prepare a statement?" "Can I ping the DB?" I
default to expected, and let the module handle the exceptions.

I guess the use of eval for every DBI statement execution can hurt
performance more than all the pedantic testing to know what's already
been done But, I found I always had to use an eval anyway. I found
some rare conditions seemed to be possible that could cause an
execution to die. If I wanted to really be sure I caught every failure
and handled it gracefully, I had to do the eval anyway.

Mark
From perrin at elem.com  Tue Feb 19 11:36:57 2008
From: perrin at elem.com (Perrin Harkins)
Date: Tue Feb 19 11:37:00 2008
Subject: [cgiapp] Lazy DBI
In-Reply-To: <00e001c872de$80951820$06fe000a@gboffice.gorillabox.net>
References: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net>
	<1b9c12d0802140327q4c920a46q104e79fe85a13714@mail.gmail.com>
	<264855a00802140331n53269fa4ib01d5004bc8efa48@mail.gmail.com>
	<01f901c86f01$9fe255c0$0afe000a@gboffice.gorillabox.net>
	<47B4511D.3090608@peknet.com>
	<00e001c872de$80951820$06fe000a@gboffice.gorillabox.net>
Message-ID: <66887a3d0802190836m448961ccu5beb94ffac9d65d6@mail.gmail.com>

On Feb 19, 2008 5:02 AM, Mark Knoop <mark@rawcane.net> wrote:
> I would be interested to know of any flaws in my logic...

This is okay for CGI.  It would not be good for any persistent
environment like FastCGI, PerlEx, or mod_perl.  It those environments
it will break if your database connection times out from inactivity or
if you restart your database server (it won't reconnect on the next
request).

If you get rid of the "our $dbh" and call connect_cached() instead of
connect(), it will accomplish the same thing, but also work without
changes when you switch to a persistent environment.

- Perrin
From mark at rawcane.net  Tue Feb 19 11:40:42 2008
From: mark at rawcane.net (Mark Knoop)
Date: Tue Feb 19 11:40:46 2008
Subject: [cgiapp] Lazy DBI
References: <01ae01c86ef8$ab7622d0$0afe000a@gboffice.gorillabox.net><1b9c12d0802140327q4c920a46q104e79fe85a13714@mail.gmail.com><264855a00802140331n53269fa4ib01d5004bc8efa48@mail.gmail.com><01f901c86f01$9fe255c0$0afe000a@gboffice.gorillabox.net><47B4511D.3090608@peknet.com><00e001c872de$80951820$06fe000a@gboffice.gorillabox.net>
	<66887a3d0802190836m448961ccu5beb94ffac9d65d6@mail.gmail.com>
Message-ID: <030801c87316$2b2d6850$06fe000a@gboffice.gorillabox.net>


> On Feb 19, 2008 5:02 AM, Mark Knoop <mark@rawcane.net> wrote:
>> I would be interested to know of any flaws in my logic...
> 
> This is okay for CGI.  It would not be good for any persistent
> environment like FastCGI, PerlEx, or mod_perl.  It those environments
> it will break if your database connection times out from inactivity or
> if you restart your database server (it won't reconnect on the next
> request).

This is a pre-sorting-mod_perl-out workaround. Thanks for the tip though.

Mark
From mark at rawcane.net  Wed Feb 20 10:23:53 2008
From: mark at rawcane.net (Mark Knoop)
Date: Wed Feb 20 10:23:59 2008
Subject: [cgiapp] CGI::Application Testing Methodologies
Message-ID: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>

Hi

####

Testing
-------

CGI::Application currently has no built-in testing methodology but we leave 
that up to you. There are many testing structures and frameworks that are 
available for testing Perl modules (ie, Test::Harness, Test::More). There 
are large numbers of tools and frameworks for testing live web applications 
(WWW::Mechanize, HTTP::Test, Apache::Test). We encourage you to look around 
CPAN and find the one that best meets your needs.

####

I read this. But being both new to CGI::Application and a bit green on 
implementing proper test plans I wondered whether anyone knows of an article 
or tutorial that covers this area?

Failing that any one sentence pointers on which approaches work for others 
would be much appreciated.

Mark 

From julio.fraire at gmail.com  Wed Feb 20 10:42:39 2008
From: julio.fraire at gmail.com (Julio Fraire)
Date: Wed Feb 20 10:42:42 2008
Subject: [cgiapp] CGI::Application Testing Methodologies
In-Reply-To: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
References: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
Message-ID: <735e91ff0802200742g7874cff2lcd0943ab20b18068@mail.gmail.com>

There is also a very good book on Perl's testing frameworks which includes a
chapter on testing live web apps:

http://www.oreilly.com/catalog/perltestingadn/

It's a really ejoyable book.

Regards,

Julio

On Wed, Feb 20, 2008 at 9:23 AM, Mark Knoop <mark@rawcane.net> wrote:

> Hi
>
> ####
>
> Testing
> -------
>
> CGI::Application currently has no built-in testing methodology but we
> leave
> that up to you. There are many testing structures and frameworks that are
> available for testing Perl modules (ie, Test::Harness, Test::More). There
> are large numbers of tools and frameworks for testing live web
> applications
> (WWW::Mechanize, HTTP::Test, Apache::Test). We encourage you to look
> around
> CPAN and find the one that best meets your needs.
>
> ####
>
> I read this. But being both new to CGI::Application and a bit green on
> implementing proper test plans I wondered whether anyone knows of an
> article
> or tutorial that covers this area?
>
> Failing that any one sentence pointers on which approaches work for others
> would be much appreciated.
>
> Mark
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
From Bill.Costa at unh.edu  Wed Feb 20 10:46:44 2008
From: Bill.Costa at unh.edu (Bill.Costa@unh.edu)
Date: Wed Feb 20 10:46:54 2008
Subject: [cgiapp] CGI::Application Testing Methodologies
In-Reply-To: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
References: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
Message-ID: <Pine.LNX.4.64.0802201043230.21031@epic.unh.edu>


> I wondered whether anyone knows of an article 
> or tutorial that covers this area?

      Perl Testing: A Developer's Notebook

      http://www.oreilly.com/catalog/perltestingadn/

      Highly recommended.  This book is in Safari Books Online
      if you are a subscriber.


                                                     ...BC

-- 
+-------------------------[ Bill.Costa@UNH.EDU ]---+
| Bill Costa                                       |  No good
| 1 Leavitt Lane                 Voice:            |   deed...
|   CIS/Telecom -- 2nd Floor       +1-603-862-3056 |
|   University of New Hampshire                    |  Goes
| Durham, NH  03824       USA                      |   unpunished.
+---------------[ http://pubpages.unh.edu/~wfc/ ]--+
From jason at journalistic.com  Wed Feb 20 10:57:05 2008
From: jason at journalistic.com (Jason Purdy)
Date: Wed Feb 20 10:56:42 2008
Subject: [cgiapp] CGI::Application Testing Methodologies
In-Reply-To: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
References: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
Message-ID: <47BC4DD1.1070004@journalistic.com>

Hi Mark,

This is a great topic and we have discussed it before on this list (we 
should really update the wiki page).

That said, writing webapp tests are really hard these days, what with 
AJAX and other JavaScript niceties not being supported in WWW::Mech. 
Then there's the spectrum of which layer do you want to test on? 
Library layer, CGIApp layer, Apache layer or web browser layer.

My advice would be to factor your code such that the code is separated 
into a testable module.  If your delete_customer function works as 
expected, then all the layers above should work as well since those 
layers are independently tested.

My advice goes without reading the previously touted Testing book, which 
I plan on reading at some point.  My advice also goes without seeing 
mpeters' response, which if he does, will offer more truth and 
experience. :)

- Jason

Mark Knoop wrote:
> Hi
> 
> ####
> 
> Testing
> -------
> 
> CGI::Application currently has no built-in testing methodology but we 
> leave that up to you. There are many testing structures and frameworks 
> that are available for testing Perl modules (ie, Test::Harness, 
> Test::More). There are large numbers of tools and frameworks for testing 
> live web applications (WWW::Mechanize, HTTP::Test, Apache::Test). We 
> encourage you to look around CPAN and find the one that best meets your 
> needs.
> 
> ####
> 
> I read this. But being both new to CGI::Application and a bit green on 
> implementing proper test plans I wondered whether anyone knows of an 
> article or tutorial that covers this area?
> 
> Failing that any one sentence pointers on which approaches work for 
> others would be much appreciated.
> 
> Mark
> 
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
From Bill.Costa at unh.edu  Wed Feb 20 11:18:44 2008
From: Bill.Costa at unh.edu (Bill.Costa@unh.edu)
Date: Wed Feb 20 11:18:54 2008
Subject: [cgiapp] CGI::Application Testing Methodologies
In-Reply-To: <47BC4DD1.1070004@journalistic.com>
References: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
	<47BC4DD1.1070004@journalistic.com>
Message-ID: <Pine.LNX.4.64.0802201104450.23400@epic.unh.edu>


> My advice would be to factor your code such that the code is
> separated into a testable module.

      This is excellent advice.  Try and write your 'back end'
      modules so that a browser is not needed to exercise them.
      Then for testing you write a simple script that can be
      executed from the command line to fully test all of the
      services provided by your module.  It then becomes a much
      simpler matter to create a test script that probes all of
      the expected operations as well as the boundary conditions
      and even pathological cases.  In other words, don't assume
      that service will always be given sane data from the front
      end.  Test for possible inputs that "should never happen".

      The book cited earlier will help you write those command
      line test scripts in a very efficient manner using well
      established and vetted test harness modules.

      An added benefit to this approach is, when you later have to
      make a change to one of these modules, you can run your
      tester to make sure you didn't accidentally break something
      else in the process.

      In this way testing the final app itself should be more
      about usability testing with humans rather than actually
      trying to test the correct functioning of lower level
      functions through the app's web interface.

                                                     ...BC

-- 
+-------------------------[ Bill.Costa@UNH.EDU ]---+
| Bill Costa                                       |  No good
| 1 Leavitt Lane                 Voice:            |   deed...
|   CIS/Telecom -- 2nd Floor       +1-603-862-3056 |
|   University of New Hampshire                    |  Goes
| Durham, NH  03824       USA                      |   unpunished.
+---------------[ http://pubpages.unh.edu/~wfc/ ]--+
From hartzell at alerce.com  Wed Feb 20 14:39:50 2008
From: hartzell at alerce.com (George Hartzell)
Date: Wed Feb 20 14:39:52 2008
Subject: [cgiapp] CGI::Application Testing Methodologies
In-Reply-To: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
References: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
Message-ID: <18364.33286.2852.708563@almost.alerce.com>

Mark Knoop writes:
 > [...]
 > I read this. But being both new to CGI::Application and a bit green on 
 > implementing proper test plans I wondered whether anyone knows of an article 
 > or tutorial that covers this area?
 > 
 > Failing that any one sentence pointers on which approaches work for others 
 > would be much appreciated.

It doesn't address any of the higher level "shoulds" associated with
testing, but be sure to look at:

   Test::WWW::Mechanize::CGIApp

for a simple way to actually *do* whatever testing you decide that you
need.

I cobbled it together a while back in response to a note on the cgiapp
site and it's been useful.

Feedback would be welcome.

g.
From silent2600 at gmail.com  Wed Feb 20 20:59:22 2008
From: silent2600 at gmail.com (Silent)
Date: Wed Feb 20 20:59:26 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
Message-ID: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>

Hi all,

has anyone use C-A-Dispatch with FastCGI ?
I can not make it work:

my code structure:
/APP/Base.pm   ### the base pm used by Admin/User
/APP/Admin.pm
/APP/User.pm
/APP/Dispatch.pm  ### the C-A-Dispatch table
app.fcgi

I have tryed "use base 'CGI::Application::FastCGI' "  in the Base.pm, but
the dispatch() not work, I always got the default app::run_mode

2. after search from google, I tryed:


#!/usr/bin/perl

use lib ".";
use CGI::Fast qw(:standard);
use APP::Dispatch;
while (my $q = CGI::Fast ) {
        APP::Dispatch->dispatch(
        args_to_new => { QUERY => $q },
      );
}

and use C-A in Base.pm
but the http header and run_mode output all dumped to apache error_log and
seems in a endless loop



needing help, thanks!
From mark at rawcane.net  Thu Feb 21 02:19:49 2008
From: mark at rawcane.net (Mark Knoop)
Date: Thu Feb 21 02:19:55 2008
Subject: [cgiapp] CGI::Application Testing Methodologies
References: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
	<18364.33286.2852.708563@almost.alerce.com>
Message-ID: <01df01c8745a$251a7a30$06fe000a@gboffice.gorillabox.net>

Thanks for all the feedback - I actually own the book mentioned though 
previously had only had the chance to skim read it. I am glad to have a good 
reason to spend some proper time with it in a real world scenario and be 
confident that it will be time well spent.

I have also taken note of the point about creating testable classes. As an 
OO newbie much of my time recently has been spent deliberating over how to 
design my classes, what to encapsulate where, what return values to use for 
methods etc. and I suspect that developing with testing in mind will 
actually help rationalize these matters.

Best
Mark


From ron at savage.net.au  Thu Feb 21 03:51:02 2008
From: ron at savage.net.au (Ron Savage)
Date: Thu Feb 21 03:49:56 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
Message-ID: <1203583862.6436.5.camel@zoe.savage.net.au>

On Thu, 2008-02-21 at 09:59 +0800, Silent wrote:

Hi Slient

> has anyone use C-A-Dispatch with FastCGI ?

I had no trouble using it. I can send my code it that helps.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From dsteinbrunner at pobox.com  Thu Feb 21 05:29:44 2008
From: dsteinbrunner at pobox.com (David Steinbrunner)
Date: Thu Feb 21 05:29:49 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
Message-ID: <C3E2BCC8.FFEC%dsteinbrunner@pobox.com>

Silent wrote:

> has anyone use C-A-Dispatch with FastCGI ?

<snip>

> 2. after search from google, I tryed:
> 
> 
> #!/usr/bin/perl
> 
> use lib ".";
> use CGI::Fast qw(:standard);
> use APP::Dispatch;
> while (my $q = CGI::Fast ) {
>         APP::Dispatch->dispatch(
>         args_to_new => { QUERY => $q },
>       );
> }

Looks comparable to code I have working with the exception of a new on the
CGI::Fast call:

  while ( my $q = CGI::Fast->new ) {

I'm also sending a value in the default param of dispatch.  For you that
value would likely be 'User'.

Beyond those thoughts you might want to look into the debug param and work
with it to see if any light can be shed on things.

--
David Steinbrunner


From dsteinbrunner at pobox.com  Thu Feb 21 05:59:35 2008
From: dsteinbrunner at pobox.com (David Steinbrunner)
Date: Thu Feb 21 05:59:43 2008
Subject: [cgiapp] CGI::Application Testing Methodologies
In-Reply-To: <47BC4DD1.1070004@journalistic.com>
Message-ID: <C3E2C3C7.FFEE%dsteinbrunner@pobox.com>

Jason Purdy wrote:

> My advice would be to factor your code such that the code is separated
> into a testable module.  If your delete_customer function works as
> expected, then all the layers above should work as well since those
> layers are independently tested.

My awareness of testing is that there are two main types, what I'll refer to
as unit testing and functional testing.  Unit testing is what Jason is
talking about above.  Having a strong base on which to build applications on
gives you confidence and is a must if you are serious about automated
testing.  The thing is, if you are dealing with a MVC
(Model-View-Controller) system then you only have your model accounted for
without coverage for the V and C bits.

Functional testing is where you test at the level of what the user interacts
with and deals with test cases your customer could specify.  For instance,
your customer wants to make sure when x is selected y can not also be
selected with out the form returning an error.  Using Test::More and
WWW::Mechanize, maybe a dash of HTML::TreeBuilder, you can automate that
type of test.  Of course, there is a little bit more to it since many
applications these days have lots of JS logic and you application likely
deals with data from a databases that you will want to have be consistent
for your tests but you can handle those for the most part if you get
creative.  It also appears that Selenium is getting a lot of attention by
developers for functional testing but I have yet to use it.  A search on
CPAN shows lots of results for Selenium, too.

In any case, I just wanted to make sure that the idea of testing both from
the bottom and the top in an automated fashion was talked about together.

--
David Steinbrunner


From silent2600 at gmail.com  Thu Feb 21 07:08:48 2008
From: silent2600 at gmail.com (Silent)
Date: Thu Feb 21 07:08:51 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
Message-ID: <4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>

2008/2/21, David Steinbrunner <dsteinbrunner@pobox.com>:
>
> Silent wrote:
>
> > has anyone use C-A-Dispatch with FastCGI ?
>
>
> <snip>
>
>
> > 2. after search from google, I tryed:
> >
> >
> > #!/usr/bin/perl
> >
> > use lib ".";
> > use CGI::Fast qw(:standard);
> > use APP::Dispatch;
> > while (my $q = CGI::Fast ) {
> >         APP::Dispatch->dispatch(
> >         args_to_new => { QUERY => $q },
> >       );
> > }
>
>
> Looks comparable to code I have working with the exception of a new on the
> CGI::Fast call:
>
>   while ( my $q = CGI::Fast->new ) {
>
> I'm also sending a value in the default param of dispatch.  For you that
> value would likely be 'User'.
>
> Beyond those thoughts you might want to look into the debug param and work
> with it to see if any light can be shed on things.
>
> --
>
> David Steinbrunner
>
>
>

OMG, I am so careless,
thanks all !
From ron at savage.net.au  Fri Feb 22 19:04:31 2008
From: ron at savage.net.au (Ron Savage)
Date: Fri Feb 22 19:03:24 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
Message-ID: <1203725071.6436.37.camel@zoe.savage.net.au>

On Thu, 2008-02-21 at 20:08 +0800, Silent wrote:

Hi Silent

Here's a demo:
http://savage.net.au/Perl-modules/CGI-Application-Test-Dispatch-1.00.tgz
Note: Test is used in the sense of testing my understanding of the
dispatch style of app design in order to write an app, not in the sense
of testing a pre-existing app. This module won't ever be on CPAN.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ron at savage.net.au  Fri Feb 22 19:12:49 2008
From: ron at savage.net.au (Ron Savage)
Date: Fri Feb 22 19:12:18 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
Message-ID: <1203725569.6436.39.camel@zoe.savage.net.au>

On Thu, 2008-02-21 at 20:08 +0800, Silent wrote:

Hi Silent

Oops. I should mention the code has a few hard-coded paths
like /home/ron/... embedded here and there.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From pagaltzis at gmx.de  Sat Feb 23 08:02:26 2008
From: pagaltzis at gmx.de (Aristotle Pagaltzis)
Date: Sat Feb 23 08:22:32 2008
Subject: [cgiapp] Re: CGI::Application Testing Methodologies
In-Reply-To: <01df01c8745a$251a7a30$06fe000a@gboffice.gorillabox.net>
References: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>
	<18364.33286.2852.708563@almost.alerce.com>
	<01df01c8745a$251a7a30$06fe000a@gboffice.gorillabox.net>
Message-ID: <20080223130226.GG26323@klangraum>

* Mark Knoop <mark@rawcane.net> [2008-02-21 08:20]:
> I have also taken note of the point about creating testable
> classes. As an OO newbie much of my time recently has been
> spent deliberating over how to design my classes, what to
> encapsulate where, what return values to use for methods etc.
> and I suspect that developing with testing in mind will
> actually help rationalize these matters.

Very helpful in this regard is doing test-first development. It
takes a bit of time to get the hang of it, because it requires
some imagination: you don?t normally think in terms of how a
non-existent API would look like.

The benefit is that it forces you to write code that *uses* an
interface before you write the code that *implements* it; this
way, it drives you toward designing your interfaces from the
perspective of a user rather than from the perspective of the
implementer. As a result, they?ll tend to be much more usable,
regardless of how deeply you understand what makes an interface
better and how much of a conscious effort you make to apply your
understanding.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
From azfuller at gmail.com  Sat Feb 23 12:01:18 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sat Feb 23 12:01:21 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <1203725071.6436.37.camel@zoe.savage.net.au>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
Message-ID: <d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>

On Fri, Feb 22, 2008 at 5:04 PM, Ron Savage <ron@savage.net.au> wrote:
>  Here's a demo:

This might be better asked on Perlmonks, but do you have a feel for
how widely used is fastcgi? I got the impression it's not because the
CPAN module isn't easy to find. Searching CPAN for "fcgi" returns a
catalyst module (MojoMojo with a ridiculous version number) instead of
the real FCGI module[1]. The module hasn't been updated since 2002.

Have you looked at any other persistence tools? I've seen references
to speedyCGI (aka persistentPerl) and pperl (CPAN module). But, I get
the impression they're not widely used because they haven't been
updated in awhile. (2003 and 2004 respectively.). I couldn't compile
speedyCGI. (But, I noticed Ubuntu 7.10 has an installable module in
its repository.). I haven't tried pperl yet. It looks like it was
created because the author couldn't compile SpeedyCGI either.

I'm just trying to understand what's commonly used. I feel like I'm
missing something because I've heard it's desirable to use something
other than mod_perl because 1) it's a bad idea to run Perl within the
web server, and 2) web hosters may not make it available. But, looking
around, looking around it's not clear to me what people are using.

[1] http://search.cpan.org/~skimo/FCGI-0.67/FCGI.PL

Thanks,
Mark
From mpeters at plusthree.com  Sat Feb 23 13:13:52 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Sat Feb 23 13:16:40 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
Message-ID: <47C06260.1030104@plusthree.com>

Mark Fuller wrote:

> I'm just trying to understand what's commonly used. I feel like I'm
> missing something because I've heard it's desirable to use something
> other than mod_perl because 

Well, I've heard... :)
Actually my opinions on this are actually based experience. I've been developing
and maintaining applications under mod_perl for at least 7 years.

> 1) it's a bad idea to run Perl within the
> web server, and 

Why? Embedding languages is a very common thing to do. Not just Perl in Apache
(or Python, Ruby, PHP, etc in Apache) but most Java application servers are the
same way.

> 2) web hosters may not make it available. 

Yes, it's true that a lot of simple web hosts don't allow mod_perl because it
means that you can actually mess up other people who are using mod_perl too in
the same server. But this is the same with mod_php too. It's not used very much
either.

But in all honesty, just buy a dedicated server. You can get a starter for
$30-50 a month and then you can put all the sites you want on it. And you won't
have to worry about asking the hosting provider to update some CPAN module or
install some library.

Sure you'll have to learn a few admin skills, but that's just more skills for
your resume (and even most dedicated servers come with a web admin panel). If I
had to pick between 2 people to hire who have similar skills and one has always
written apps that only run on shared servers but the other wrote for a dedicated
server. Guess which one I would hire?

-- 
Michael Peters
Plus Three, LP

From ron at savage.net.au  Sat Feb 23 18:12:50 2008
From: ron at savage.net.au (Ron Savage)
Date: Sat Feb 23 18:14:03 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
Message-ID: <1203808370.6436.78.camel@zoe.savage.net.au>

On Sat, 2008-02-23 at 10:01 -0700, Mark Fuller wrote:

Hi Mark

I see Michael Peters has already replied, and he know a great deal more
that I do about these topics. Nevertheless, a few comments follow...

> This might be better asked on Perlmonks, but do you have a feel for
> how widely used is fastcgi? I got the impression it's not because the

I have no idea how widely FastCGI is used, although I occassionally see
references to it (still being used). I tried it because I'd heard about
it and because I wanted to familiarize myself with
yet-another-way-of-doing-things.

> CPAN module isn't easy to find. Searching CPAN for "fcgi" returns a
> catalyst module (MojoMojo with a ridiculous version number) instead of
> the real FCGI module[1]. The module hasn't been updated since 2002.

Curious. Still, reliable (software) technology doesn't have to be
updated. This topic blew up - on this list - a couple of years ago, and
I responded /very/ briefly with a comment about Perl on Prozac, because
I got the distinct impression the OP was under pressure to fabricate the
false impression of the introduction of new software technology into the
marketplace by artifically creating new versions, or new names for old
packages, in order to give their employer a false but perceived
advantage (in the market). But things like CGI, HTML, HTTP, TCP/IP etc
don't need constant updating. We rely of them precisely because they can
be relied upon (which sounds like a circular argument, but then the
traffic flow from web client to web server and back is circular too!).

> Have you looked at any other persistence tools? I've seen references
> to speedyCGI (aka persistentPerl) and pperl (CPAN module). But, I get

Yes. IIRC I downloaded SpeedyCGI but could not compile it due to syntax
errors. In such a situation I immediately wrote it off, and that because
there are such good and working alternatives - FastCGI and mod_perl.

Note: These latter 2 technologies do not - to my way of thinking -
address the same issues, so I don't see them completing with each other.
Nevertheless they can have the same effect (as each other) by vastly
speeding up execution times by caching compiled code.

> the impression they're not widely used because they haven't been
> updated in awhile. (2003 and 2004 respectively.). I couldn't compile
> speedyCGI. (But, I noticed Ubuntu 7.10 has an installable module in
> its repository.). I haven't tried pperl yet. It looks like it was
> created because the author couldn't compile SpeedyCGI either.

Ubuntu - ha, ha, ha. 

Last year I installed FreeBSD twice, Ubuntu several times, Debian
several times, (and OpenBSD several years ago), in order to choose what
to abandon Windows in favour of. To say Ubuntu was a fucking shambles
would be to glorify it. I posted a very long explanation on the Ubuntu
forum's installation survey at the time. I chose Debian. Case closed.

> I'm just trying to understand what's commonly used. I feel like I'm
> missing something because I've heard it's desirable to use something
> other than mod_perl because 1) it's a bad idea to run Perl within the
> web server, and 2) web hosters may not make it available. But, looking
> around, looking around it's not clear to me what people are using.

Besides Michael's reply I can add:

o Re Apache's internal processing steps in constructing it's reply:
mod_perl offers the extreme example of allowing the programmer to
intervene in those steps. Hence it's the definitive tool if intervention
is appropriate. But is it always? Of course not. That's when FastCGI is
a reasonable alternative. My preference, however, is that since mod_perl
offers so much, there's no real need to use FastCGI at all. Even so, I'm
curious enough about FastCGI to study it, albeit briefly, so I can write
a little demo to satisfy myself, and then move up to mod_perl
permanently

o Yep, I decided, recently, to get a dedicated server too, although I
haven't actually done that yet. Bandwagons R Us! The other prompt was a
recent offer from my web hosting company (QuadraHosting via their
Australian office - recommended), of new shared and dedicated server
products. They run Centros as their OS, and call these services VPS:
Virtual Private Server. See:
http://www.quadrahosting.com.au/vps/linux-vps.html
for what we pay over here (shudder)

HTH.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From silent2600 at gmail.com  Sat Feb 23 22:02:48 2008
From: silent2600 at gmail.com (Silent)
Date: Sat Feb 23 22:02:50 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <1203725071.6436.37.camel@zoe.savage.net.au>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
Message-ID: <4f9acfca0802231902g113099c2v35d5ae61f75d6d7a@mail.gmail.com>

2008/2/23, Ron Savage <ron@savage.net.au>:
>
> On Thu, 2008-02-21 at 20:08 +0800, Silent wrote:
>
> Hi Silent
>
> Here's a demo:
> http://savage.net.au/Perl-modules/CGI-Application-Test-Dispatch-1.00.tgz
> Note: Test is used in the sense of testing my understanding of the
> dispatch style of app design in order to write an app, not in the sense
> of testing a pre-existing app. This module won't ever be on CPAN.
> --


thanks very much!
that's works,
and in t.fcgi:

the line "$request -> Finish();" seems not needed.


and in my opinion, mod_perl is powerfull, but Fastcgi is also very fast than
CGI,
and it is more easyer to find vhost surport fastcgi than mod_perl.
From azfuller at gmail.com  Sat Feb 23 23:34:27 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sat Feb 23 23:34:30 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <1203808370.6436.78.camel@zoe.savage.net.au>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
	<1203808370.6436.78.camel@zoe.savage.net.au>
Message-ID: <d69cc4a60802232034n7004978dwd1605b4c69d2f4cc@mail.gmail.com>

>  Curious. Still, reliable (software) technology doesn't have to be
>  updated. This topic blew up

Sorry. It just looked like nothing was happening with these various
tools. For example: The SpeedyCGI/PersistentPerl web site has binaries
for download which are ancient. The fastcgi site's FAQ has a "what is
fastcgi?" placeholder that hasn't been completed. Things like that
give the impression there isn't much user base. For example, if
someone heard of fastcgi how would they find the FCGI module? For the
life of me, I can't figure out how to find it on CPAN without already
knowing where it is. :) Taken as a sum I gather impressions. That's
all.

> in order to choose what
>  to abandon Windows in favour of. To say Ubuntu was a f***ing shambles
>  would be to glorify it. I posted a very long explanation on the Ubuntu
>  forum's installation survey at the time. I chose Debian. Case closed.

I've not had any problems with Ubuntu. But, I just use the server
distribution. I should probably use CentOS as a more serious server
distro. But, I like how Ubuntu has broad (fanatical?) user support. I
notice the speedyCGI package is in the Debian repository too. That
might be where Ubuntu got it. (wink).

I didn't realize you only tested fastcgi (not an active user).

SpeedyCGI and "pperl" on CPAN) (if they work) seem to be more
transparent. They don't require a lot of change to the script (just
the shebang line). They have options to automatically terminate after
a number of executions, or amount of time. I've have code these tests
into my fastcgi "accept" loop (which is already a significant
modification to non-fastcgi processing.).

Mark
From ron at savage.net.au  Sun Feb 24 00:41:25 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Feb 24 00:43:11 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <4f9acfca0802231902g113099c2v35d5ae61f75d6d7a@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<4f9acfca0802231902g113099c2v35d5ae61f75d6d7a@mail.gmail.com>
Message-ID: <1203831685.15917.4.camel@zephyr>

Hi Silent

> thanks very much!
> that's works,
> and in t.fcgi:

Excellent.

> the line "$request -> Finish();" seems not needed.

True. But it's a good habit to get into...

> and in my opinion, mod_perl is powerfull, but Fastcgi is also very fast than
> CGI,
> and it is more easyer to find vhost surport fastcgi than mod_perl.

I doubt that! The mod_perl mailing list is /very/ active.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ron at savage.net.au  Sun Feb 24 00:44:20 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Feb 24 00:44:10 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <d69cc4a60802232034n7004978dwd1605b4c69d2f4cc@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
	<1203808370.6436.78.camel@zoe.savage.net.au>
	<d69cc4a60802232034n7004978dwd1605b4c69d2f4cc@mail.gmail.com>
Message-ID: <1203831860.15917.7.camel@zephyr>

Hi Mark

> life of me, I can't figure out how to find it on CPAN without already
> knowing where it is. :) Taken as a sum I gather impressions. That's
> all.

IIRC there's a link from the FastCGI web site to the CPAN module.

> SpeedyCGI and "pperl" on CPAN) (if they work) seem to be more
> transparent. They don't require a lot of change to the script (just
> the shebang line). They have options to automatically terminate after
> a number of executions, or amount of time. I've have code these tests
> into my fastcgi "accept" loop (which is already a significant
> modification to non-fastcgi processing.).

A few lines of change is not worth worrying about. Other matters should
decide which way you jump.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From azfuller at gmail.com  Sun Feb 24 00:57:26 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sun Feb 24 00:57:29 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <1203831860.15917.7.camel@zephyr>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
	<1203808370.6436.78.camel@zoe.savage.net.au>
	<d69cc4a60802232034n7004978dwd1605b4c69d2f4cc@mail.gmail.com>
	<1203831860.15917.7.camel@zephyr>
Message-ID: <d69cc4a60802232157k7a0874e2pf6b564f31334203f@mail.gmail.com>

>  IIRC there's a link from the FastCGI web site to the CPAN module.

Can you provide a link to the site that provides the link? :) If I go
to www.fastcgi.com it has a link to CPAN's main page.

The only way I found FCGI in the past was to browse FCGI::ProcManager
(which turned up in a search for FCGI). It has a link to FCGI.

BTW: The speedyCGI package installed with Ubuntu 7.10 (probably the
same package available in Debian) seems to work. I'm not sure what
version of Perl I'm getting. But, it's a pretty simple way to play
with persistence without going through a web server. An easy way to
see how class and object data differ.

>A few lines of change is not worth worrying about.

Another thing is testing if the script's source changed. The
documentation for the fastcgi perl handler has an option to test for
this, but it says it's better for the fcgi script to test if the
source changed.

It adds up.

Mark
From ron at savage.net.au  Sun Feb 24 01:13:44 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Feb 24 01:13:35 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <d69cc4a60802232157k7a0874e2pf6b564f31334203f@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
	<1203808370.6436.78.camel@zoe.savage.net.au>
	<d69cc4a60802232034n7004978dwd1605b4c69d2f4cc@mail.gmail.com>
	<1203831860.15917.7.camel@zephyr>
	<d69cc4a60802232157k7a0874e2pf6b564f31334203f@mail.gmail.com>
Message-ID: <1203833624.15917.19.camel@zephyr>

Hi Mark


> Can you provide a link to the site that provides the link? :) If I go
> to www.fastcgi.com it has a link to CPAN's main page.

Go to http://www.fastcgi.com/ and scroll down to /Perl/, not /CPAN/
(between Java and Python). Takes you straight to the module.

> >A few lines of change is not worth worrying about.
> 
> Another thing is testing if the script's source changed. The
> documentation for the fastcgi perl handler has an option to test for
> this, but it says it's better for the fcgi script to test if the
> source changed.

I'd be worried about my modules changing, not the script itself...
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From azfuller at gmail.com  Sun Feb 24 01:19:43 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sun Feb 24 01:19:45 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <1203833624.15917.19.camel@zephyr>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
	<1203808370.6436.78.camel@zoe.savage.net.au>
	<d69cc4a60802232034n7004978dwd1605b4c69d2f4cc@mail.gmail.com>
	<1203831860.15917.7.camel@zephyr>
	<d69cc4a60802232157k7a0874e2pf6b564f31334203f@mail.gmail.com>
	<1203833624.15917.19.camel@zephyr>
Message-ID: <d69cc4a60802232219q784a4175xeb7d21246e7355f1@mail.gmail.com>

>  Go to http://www.fastcgi.com/ and scroll down to /Perl/, not /CPAN/
>  (between Java and Python). Takes you straight to the module.

I see what you mean. If you click on the "Perl" link it takes you to a
list of CPAN modules. Do you understand why those modules can't be
found by searching CPAN?

Mark
From ron at savage.net.au  Sun Feb 24 01:43:39 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Feb 24 01:43:31 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <d69cc4a60802232219q784a4175xeb7d21246e7355f1@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
	<1203808370.6436.78.camel@zoe.savage.net.au>
	<d69cc4a60802232034n7004978dwd1605b4c69d2f4cc@mail.gmail.com>
	<1203831860.15917.7.camel@zephyr>
	<d69cc4a60802232157k7a0874e2pf6b564f31334203f@mail.gmail.com>
	<1203833624.15917.19.camel@zephyr>
	<d69cc4a60802232219q784a4175xeb7d21246e7355f1@mail.gmail.com>
Message-ID: <1203835419.15917.23.camel@zephyr>

Hi Mark

On Sat, 2008-02-23 at 23:19 -0700, Mark Fuller wrote:
> >  Go to http://www.fastcgi.com/ and scroll down to /Perl/, not /CPAN/
> >  (between Java and Python). Takes you straight to the module.
> 
> I see what you mean. If you click on the "Perl" link it takes you to a
> list of CPAN modules. Do you understand why those modules can't be
> found by searching CPAN?

My guess is that a while ago (a couple of years) there was a problem
with the indexer at CPAN, and because the Perl for FCGI has not needed
to be updated for so long, it has not been seen by the new indexer.
Confusing, I admit.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From dave at skiddlydee.com  Sun Feb 24 03:42:53 2008
From: dave at skiddlydee.com (David Emery)
Date: Sun Feb 24 03:42:44 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <d69cc4a60802232157k7a0874e2pf6b564f31334203f@mail.gmail.com>
	(Mark Fuller's message of "Sat, 23 Feb 2008 22:57:26 -0700")
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
	<1203808370.6436.78.camel@zoe.savage.net.au>
	<d69cc4a60802232034n7004978dwd1605b4c69d2f4cc@mail.gmail.com>
	<1203831860.15917.7.camel@zephyr>
	<d69cc4a60802232157k7a0874e2pf6b564f31334203f@mail.gmail.com>
Message-ID: <87mypqwxrm.fsf@skiddlydee.com>

"Mark Fuller" <azfuller@gmail.com> writes:

> BTW: The speedyCGI package installed with Ubuntu 7.10 (probably the
> same package available in Debian) seems to work. I'm not sure what
> version of Perl I'm getting. 

You'd be getting whatever version of Perl is on that machine. 

> But, it's a pretty simple way to play
> with persistence without going through a web server. An easy way to
> see how class and object data differ.

I use speedy fairly regularly and like it a lot. Virtual server hosts I
use often run on FreeBSD, which has a port available so it's easy to
install. In the past I've been able to get a couple of shared hosting
companies to install it as well.

It works very well for me. The ability to group scripts together to
share a speedy instance, and to set config parameters in the
shebang-line are nice.

Dave
From geconomou at gmail.com  Sun Feb 24 05:34:44 2008
From: geconomou at gmail.com (Giannis Economou)
Date: Sun Feb 24 05:34:44 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <1203583862.6436.5.camel@zoe.savage.net.au>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<1203583862.6436.5.camel@zoe.savage.net.au>
Message-ID: <47C14844.3020902@gmail.com>

Hello...

I'm using fastcgi for C::A for a long time in production installations, 
with success (with C::A::Dispatch).
Actually, the best thing for me was to use the mod_fcgid module 
(http://fastcgi.coremail.cn/) instead of the old fastcgi (www.fastcgi.com).
mod_fcgid is binary compatibility to mod_fastcgi, but I like it much more.
mod_fcgid become more popular after RoR success - it seems it become 
quite common accelerator for  ruby environments nowadays.
Installation is pretty easy. And it's working reliable for accelarating 
my C::A non-stop in production environments.

In the past (before mod_fcgid) I had several experiences with speedycgi 
(aka perperl) and C::A (with Dispatch). But I abandon this, because 
there were problems. It was 2006 and I don't remember exactly the 
problems I had. I remember that I've managed to have speedycgi running 
and it seemed ok.
But the processes of speedycgi was becoming problematic after some 
days/weeks of execution. Maybe it had to do with database persistency, I 
really do not remember now. I remember also that I was very pleased to 
abandon speedy and to go to mod_fcgid.

BTW, if you are interested we offer shared hosting that is ready for 
C::A (wth mod_fcgi), in case you are interested. Our systems run CentOS 
4, 5 (and Debian, but our Debian servers are not available for shared 
hosting now).



To make a plain CGI C::A to go on Fast CGI (mod_fcgi), usually I just 
have to:
use CGI::Fast qw(:standard);
and then implement the main loop, as:
while ( my $q = new CGI::Fast ) {
...
}

I also use in the dispatch() options:
args_to_new => {
                        QUERY => $q,
                        PARAMS => {
                             '::Plugin::DBH::dbh_config' => [ sub 
{DBI->connect_cached(  
MyWebApp::Util::Config->instance->GetDbConnectionParams()  );} ],
                           },

(Util::Config->GetDbConnectionParams() just returns the connection string)

I also take care to not relyi on any relative paths in my C::A.



Best regards,
Giannis Economou


Ron Savage wrote:
> On Thu, 2008-02-21 at 09:59 +0800, Silent wrote:
>
> Hi Slient
>
>   
>> has anyone use C-A-Dispatch with FastCGI ?
>>     
>
> I had no trouble using it. I can send my code it that helps.
>   

From breadwild at gmail.com  Sun Feb 24 09:43:04 2008
From: breadwild at gmail.com (Brad Cathey)
Date: Sun Feb 24 09:43:09 2008
Subject: [cgiapp] Understanding sessions
Message-ID: <9c83f0330802240643m54adb7efsd1f7213ae06c49ce@mail.gmail.com>

Hello,

Though I'm been using CGI::App for a few years, this will sound like a
newbie thread, but bear with me--your help will be greatly
appreciated.

I'm still trying to understand queries, sessions and cookies.

First, I have read the CAP::Session docs several times and my
understanding is: (and correct me here):

1) C::A does not naturally create a session unless there is an
explicit reference to 'session', e.g., $self->session->param('userid')
2) sessions need cookies or id (that would have to be stored in a
hidden input field to maintain state)
3) unless explicitly set to false, a cookie is automatically created
when a session is created
4) the parameters for that cookie are defaulted unless cookie
parameters are explicited given
5) sessions are stored in /tmp on my server, but linked by id to a
cookie or param that I pass back and forth to my page
6) $self->query->param('userid') is not a session, and is only
applicable for that instance, or until another header is sent to the
browser
7) sessions are not deleted unless explicitly called:
$self->session_delete, however cookies expire automatically

Here's my challenge:
I have an application built on C::A and HTML::Template that starts by
displaying a login page when landing on the site, if they are not
already logged in. Of course, when checking the login param, a session
is created. If they never log in, that session is just left sitting in
/tmp. My /tmp directory is filled with thousands of sessions that are
not getting deleted.

Questions:
1. how can those unnecessary sessions be deleted?
2. where are the actual session->params stored?

Thanks!
Brad
From azfuller at gmail.com  Sun Feb 24 11:24:50 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sun Feb 24 11:24:53 2008
Subject: [cgiapp] Understanding sessions
In-Reply-To: <9c83f0330802240643m54adb7efsd1f7213ae06c49ce@mail.gmail.com>
References: <9c83f0330802240643m54adb7efsd1f7213ae06c49ce@mail.gmail.com>
Message-ID: <d69cc4a60802240824k6475e36awaf0ad8cf7aa4c83c@mail.gmail.com>

>  1. how can those unnecessary sessions be deleted?

If you're on a unix system you can use the "find" command with the
"-mtime" option to find files in a directory older than a certain time
(-name to limit it to a certain pattern of filename). If you're not on
unix you could write a simple Perl script to do the same thing,
looping through all the filenames in a directory, using one of the -x
built-in functions. It would be simple. Pass it a path on the command
line, out put filenames in the stdout that could be used in a shell
loop to remove the files.

Usually "store" cleanup is something done outside the session tool.
You're using files for the session store. I use cache::cache[1].
Others use postgres. I think it's expected everyone does their own
cleanup of stores for sessions that haven't been visited after some
reasonable amount of time after the expiration time.

I don't use cgi::session. Cees or Mark S. would have to explain it
more specifically. I like cache::cache[1] because it has a method to
purge expired cookies. I can use a scheduled script which does nothing
more than instantiate the cache and invoke the method. I think you'd
have to create a driver to use it with c::s. I understand c::c is
being redone as chi..pm (search CPAN for it).

[1] http://search.cpan.org/~dclinton/Cache-Cache-1.05/lib/Cache/Cache.pm

Mark
From azfuller at gmail.com  Sun Feb 24 12:19:17 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sun Feb 24 12:19:21 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <47C14844.3020902@gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<1203583862.6436.5.camel@zoe.savage.net.au>
	<47C14844.3020902@gmail.com>
Message-ID: <d69cc4a60802240919o3df852axfc1c089ae6f130a0@mail.gmail.com>

On Sun, Feb 24, 2008 at 3:34 AM, Giannis Economou <geconomou@gmail.com> wrote:
>  Actually, the best thing for me was to use the mod_fcgid module
>  (http://fastcgi.coremail.cn/) instead of the old fastcgi (www.fastcgi.com).
>  mod_fcgid is binary compatibility to mod_fastcgi, but I like it much more.

Thanks. I wasn't aware there was a fastcgi and fastcgid. It sounds
like this is just a change at the Apache server, not the instance
script? You continue to use FCGI.pl? (There's not an FCGId.pl?).

I googled and found a couple of people saying the "d" handler is
unstable (one said it's "more unstable than a monkey on crack"). That
was posted in the past 60 days. Have you had any problems?

>  In the past (before mod_fcgid) I had several experiences with speedycgi
>  (aka perperl)

*Another* name (perperl) for speedyCGI/persistentPerl :). That made
finding it difficult for me. I read in the POD that persistentPerl was
supposed to become the name going forward. That was back in 2002. I
spent about an hour trying to find it. By chance I tried "speedyCGI"
and found an up-to-date package in Ubuntu's repository. I never tried
"perperl." (Which is confusingly similar to pperl, an entirely
different module on CPAN).

It's confusing. This discussion's clarified a lot of things.

To Ron: I emailed Sven, asking if he could reindex FCGI. He was very
responsive. I received a reply in 10 minutes that he'd done it. (Just
to let you know that discussion led to something productive.). If it
doesn't appear in the search results by tomorrow I'll nag him a little
more about it. Maybe it's not a big deal. But, it was always confusing
to me that it's not discoverable through CPAN. It gave me the
impression it wasn't really "mainstream."

Mark
From azfuller at gmail.com  Sun Feb 24 13:47:16 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sun Feb 24 13:47:43 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <87mypqwxrm.fsf@skiddlydee.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<C3E2BCC8.FFEC%dsteinbrunner@pobox.com>
	<4f9acfca0802210408q43c4cdb5j44cb575da3e447de@mail.gmail.com>
	<1203725071.6436.37.camel@zoe.savage.net.au>
	<d69cc4a60802230901v52c310e8s3da369a0ec5cd646@mail.gmail.com>
	<1203808370.6436.78.camel@zoe.savage.net.au>
	<d69cc4a60802232034n7004978dwd1605b4c69d2f4cc@mail.gmail.com>
	<1203831860.15917.7.camel@zephyr>
	<d69cc4a60802232157k7a0874e2pf6b564f31334203f@mail.gmail.com>
	<87mypqwxrm.fsf@skiddlydee.com>
Message-ID: <d69cc4a60802241047h3efd952fk9fa253af1779cefe@mail.gmail.com>

On Sun, Feb 24, 2008 at 1:42 AM, David Emery <dave@skiddlydee.com> wrote:
>
>  You'd be getting whatever version of Perl is on that machine.

Thanks. I had the idea that it was creating it's own statically linked
Perl executable.

>  It works very well for me. The ability to group scripts together to
>  share a speedy instance, and to set config parameters in the
>  shebang-line are nice.

I like it too. Especially the ability to play with it at the command
line. 2-3 years ago I went through the learning curve figuring out the
subtle differences between persistence and non-persistence (the
difference between class and object data, how begin and end blocks
work, etc.). That would have been a lot easier at the command line
instead of experimenting with a CGI. I think there's a way to hook up
a command line script to a FCGI script through a pipe or unix socket.
But, I haven't looked at it closely.

I like how there's not much to change to switch to mod_perl. I'm
trying to think if there's a way to make common FCGI processing a
plugin so it would just be a one-line change. I saw
CGI::Application:FastCGI:

http://search.cpan.org/~naoya/CGI-Application-FastCGI-0.02/lib/CGI/Application/FastCGI.pm

A superclass between you and C::A. But, it looks like the object never
goes out of focus. I guess that could lead to coding that wouldn't
behave the same way under mod_perl or native fcgi.

Mark
From breadwild at gmail.com  Sun Feb 24 14:07:18 2008
From: breadwild at gmail.com (Brad Cathey)
Date: Sun Feb 24 14:07:21 2008
Subject: [cgiapp] Understanding sessions
In-Reply-To: <d69cc4a60802240824k6475e36awaf0ad8cf7aa4c83c@mail.gmail.com>
References: <9c83f0330802240643m54adb7efsd1f7213ae06c49ce@mail.gmail.com>
	<d69cc4a60802240824k6475e36awaf0ad8cf7aa4c83c@mail.gmail.com>
Message-ID: <9c83f0330802241107l6e580764rc8ae95584bac45f1@mail.gmail.com>

Mark,

That was a big help. Mainly knowing that the cleaning up of these /tmp
files outside the realm of anything in my initial application. It does
make sense. I'll work on a cron job to eliminate the dead wood every
so often.

On Sun, Feb 24, 2008 at 10:24 AM, Mark Fuller <azfuller@gmail.com> wrote:
> >  1. how can those unnecessary sessions be deleted?
>
>  If you're on a unix system you can use the "find" command with the
>  "-mtime" option to find files in a directory older than a certain time
>  (-name to limit it to a certain pattern of filename). If you're not on
>  unix you could write a simple Perl script to do the same thing,
>  looping through all the filenames in a directory, using one of the -x
>  built-in functions. It would be simple. Pass it a path on the command
>  line, out put filenames in the stdout that could be used in a shell
>  loop to remove the files.
>
>  Usually "store" cleanup is something done outside the session tool.
>  You're using files for the session store. I use cache::cache[1].
>  Others use postgres. I think it's expected everyone does their own
>  cleanup of stores for sessions that haven't been visited after some
>  reasonable amount of time after the expiration time.
>
>  I don't use cgi::session. Cees or Mark S. would have to explain it
>  more specifically. I like cache::cache[1] because it has a method to
>  purge expired cookies. I can use a scheduled script which does nothing
>  more than instantiate the cache and invoke the method. I think you'd
>  have to create a driver to use it with c::s. I understand c::c is
>  being redone as chi..pm (search CPAN for it).
>
>  [1] http://search.cpan.org/~dclinton/Cache-Cache-1.05/lib/Cache/Cache.pm
>
>  Mark
>
>  #####  CGI::Application community mailing list  ################
>  ##                                                            ##
>  ##  To unsubscribe, or change your message delivery options,  ##
>  ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
>  ##                                                            ##
>  ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
>  ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
>  ##                                                            ##
>  ################################################################
>
>
From ron at savage.net.au  Sun Feb 24 16:31:14 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Feb 24 16:30:33 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <d69cc4a60802240919o3df852axfc1c089ae6f130a0@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>
	<1203583862.6436.5.camel@zoe.savage.net.au>
	<47C14844.3020902@gmail.com>
	<d69cc4a60802240919o3df852axfc1c089ae6f130a0@mail.gmail.com>
Message-ID: <1203888674.14085.6.camel@zoe.savage.net.au>

Hi Mark

> To Ron: I emailed Sven, asking if he could reindex FCGI. He was very
> responsive. I received a reply in 10 minutes that he'd done it. (Just
> to let you know that discussion led to something productive.). If it
> doesn't appear in the search results by tomorrow I'll nag him a little
> more about it. Maybe it's not a big deal. But, it was always confusing
> to me that it's not discoverable through CPAN. It gave me the
> impression it wasn't really "mainstream."

Good idea.

Well, it may not be "mainstream", but the CPAN index sure is, and it's
the latter I'd like to know is reliable.

All in all, a productive thread.

$response = $many x $thanx;

to all who contributed. And don't stop now if you have more to say!
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ron at savage.net.au  Sun Feb 24 16:34:47 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Feb 24 16:37:13 2008
Subject: [cgiapp] Understanding sessions
In-Reply-To: <d69cc4a60802240824k6475e36awaf0ad8cf7aa4c83c@mail.gmail.com>
References: <9c83f0330802240643m54adb7efsd1f7213ae06c49ce@mail.gmail.com>
	<d69cc4a60802240824k6475e36awaf0ad8cf7aa4c83c@mail.gmail.com>
Message-ID: <1203888887.14085.9.camel@zoe.savage.net.au>

Hi Mark

On Sun, 2008-02-24 at 09:24 -0700, Mark Fuller wrote:
> >  1. how can those unnecessary sessions be deleted?
> 
> If you're on a unix system you can use the "find" command with the
> "-mtime" option to find files in a directory older than a certain time
> (-name to limit it to a certain pattern of filename). If you're not on

Jeeeeezzzzzzzzzzuzzzzzzzz! CPAN is your friend. Consider:

http://search.cpan.org/~rsavage/CGI-Session-ExpireSessions-1.08/

-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ron at savage.net.au  Sun Feb 24 16:48:02 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Feb 24 16:46:46 2008
Subject: [cgiapp] Understanding sessions
In-Reply-To: <9c83f0330802240643m54adb7efsd1f7213ae06c49ce@mail.gmail.com>
References: <9c83f0330802240643m54adb7efsd1f7213ae06c49ce@mail.gmail.com>
Message-ID: <1203889682.14085.21.camel@zoe.savage.net.au>

Hi Brad

A brief and hence partial reply.

> I'm still trying to understand queries, sessions and cookies.

No problem.

> First, I have read the CAP::Session docs several times and my
> understanding is: (and correct me here):
> 
> 1) C::A does not naturally create a session unless there is an
> explicit reference to 'session', e.g., $self->session->param('userid')

Better the think in terms of CGI::Session. That's one module that
handles sessions. Apache::Session is another.

/If/ your CGI::App uses CGI::Session (or whatever), then you get access
to session handling.

> 2) sessions need cookies or id (that would have to be stored in a
> hidden input field to maintain state)

I don't use cookies myself.

Better to think of the id as the key which enables the session manager
to identify a new session created in the session store (e.g. disk) by
the session manager, and used by the session manager to find a
pre-existing session. This automatically means you have to give the key
to the session manager when you wish to retrieve a session's data.

> 3) unless explicitly set to false, a cookie is automatically created
> when a session is created
> 4) the parameters for that cookie are defaulted unless cookie
> parameters are explicited given
> 5) sessions are stored in /tmp on my server, but linked by id to a
> cookie or param that I pass back and forth to my page

The location will be configurable in the options you pass to the session
manager.

> 6) $self->query->param('userid') is not a session, and is only
> applicable for that instance, or until another header is sent to the
> browser

True, it's not a session. It's a key passed from the client's CGI form
back to your CGI::App which you must pass to the session manager to
retrieve any pre-existing session's data.

> 7) sessions are not deleted unless explicitly called:
> $self->session_delete, however cookies expire automatically

You probably meant $self -> session() -> delete(); there.

Both this and $self -> session() -> param('userid') above only work if
$self -> session() works, and that only works if a module, e.g.
CGI::Session via (say) CGI::Application::Plugin::Session, is used in
your CGI::App. The plugin automagically forces sub session() into your
app's namespace, so you can call it with $self -> session().

> Here's my challenge:
> I have an application built on C::A and HTML::Template that starts by
> displaying a login page when landing on the site, if they are not
> already logged in. Of course, when checking the login param, a session
> is created. If they never log in, that session is just left sitting in
> /tmp. My /tmp directory is filled with thousands of sessions that are
> not getting deleted.
> 
> Questions:
> 1. how can those unnecessary sessions be deleted?

Answered in my other post.

> 2. where are the actual session->params stored?

That depends on what parameters you passed when initializing
CGI::Session.

-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From geconomou at gmail.com  Mon Feb 25 05:46:07 2008
From: geconomou at gmail.com (Giannis Economou)
Date: Mon Feb 25 05:46:22 2008
Subject: [cgiapp] how to use C::A::Dispatch with FastCGI ?
In-Reply-To: <d69cc4a60802240919o3df852axfc1c089ae6f130a0@mail.gmail.com>
References: <4f9acfca0802201759u1f97e49dq99419d05e1f180be@mail.gmail.com>	<1203583862.6436.5.camel@zoe.savage.net.au>	<47C14844.3020902@gmail.com>
	<d69cc4a60802240919o3df852axfc1c089ae6f130a0@mail.gmail.com>
Message-ID: <47C29C6F.70107@gmail.com>

Mark Fuller wrote:
> On Sun, Feb 24, 2008 at 3:34 AM, Giannis Economou <geconomou@gmail.com> wrote:
>   
>>  Actually, the best thing for me was to use the mod_fcgid module
>>  (http://fastcgi.coremail.cn/) instead of the old fastcgi (www.fastcgi.com).
>>  mod_fcgid is binary compatibility to mod_fastcgi, but I like it much more.
>>     
>
> Thanks. I wasn't aware there was a fastcgi and fastcgid. It sounds
> like this is just a change at the Apache server, not the instance
> script? You continue to use FCGI.pl? (There's not an FCGId.pl?).
>
>   
Yes, you continue using FCGI (no FCGId).
> I googled and found a couple of people saying the "d" handler is
> unstable (one said it's "more unstable than a monkey on crack"). That
> was posted in the past 60 days. Have you had any problems?
>
>   
None! No problems. Running non-stop for many months without any problem 
at all.
Give it a try.

Giannis

From peter at peknet.com  Mon Feb 25 15:05:45 2008
From: peter at peknet.com (Peter Karman)
Date: Mon Feb 25 15:05:47 2008
Subject: [cgiapp] Re: CGI::Application Testing Methodologies
In-Reply-To: <20080223130226.GG26323@klangraum>
References: <006e01c873d4$9a436c30$06fe000a@gboffice.gorillabox.net>	<18364.33286.2852.708563@almost.alerce.com>	<01df01c8745a$251a7a30$06fe000a@gboffice.gorillabox.net>
	<20080223130226.GG26323@klangraum>
Message-ID: <47C31F99.7020703@peknet.com>



Aristotle Pagaltzis wrote on 2/23/08 7:02 AM:
> * Mark Knoop <mark@rawcane.net> [2008-02-21 08:20]:
>> I have also taken note of the point about creating testable
>> classes. As an OO newbie much of my time recently has been
>> spent deliberating over how to design my classes, what to
>> encapsulate where, what return values to use for methods etc.
>> and I suspect that developing with testing in mind will
>> actually help rationalize these matters.
> 
> Very helpful in this regard is doing test-first development. It
> takes a bit of time to get the hang of it, because it requires
> some imagination: you don?t normally think in terms of how a
> non-existent API would look like.
> 
> The benefit is that it forces you to write code that *uses* an
> interface before you write the code that *implements* it; this
> way, it drives you toward designing your interfaces from the
> perspective of a user rather than from the perspective of the
> implementer. As a result, they?ll tend to be much more usable,
> regardless of how deeply you understand what makes an interface
> better and how much of a conscious effort you make to apply your
> understanding.
> 

very good advice. I've been trying to practice that approach the last few years. 
I actually start with the POD first, since that forces me to think entirely from 
the user's perspective, and then make my SYNOSIS my first test.

-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com
From jspooner at liaison-intl.com  Thu Feb 28 17:21:51 2008
From: jspooner at liaison-intl.com (John Spooner)
Date: Thu Feb 28 17:21:55 2008
Subject: [cgiapp] ValidateRM and dynamic content
Message-ID: <788CE35B4DF22443A7AA542796706AB501692F23@liex2.liaison-intl.com>

Hi all,

I am using HTML::Template and CGI::Application::Plugin::ValidateRM.
Page content is generated dynamically which works fine until a
validation error occurs.  Unfortunately <err_<TMPL_VAR field_name>> is
not valid H::T.

 

In perusing the C::A email archives I see that the same issue has been
brought up before (almost 3 years ago, but at least I know others have
suffered the same fate).  Unfortunately there was no documented
resolution.  Does anyone have any advice?

 

Here is the plea from the archives.  I am experiencing the exact same
problem:

 

Hi All

I'm writing a template for use with CGI:Application::Plugin::ValidateRM.
C::A::P::VRM expects every field that requires validation to have a =
matching
field with an "err_" prefix (i.e err_field_name).

My field names are dynamic, e.g.

<tmpl_loop name=3Dapplication_parameters>
<input type=3D"Text" name=3D"<tmpl_var name=3Dfield_name>" =
value=3D"<tmpl_var
name=3Dfield_value>
</tmpl_loop>

but I can't figure out the best way to specify the error field. =
Obviously=20

<tmpl_var name=3Derr_<tmpl_var name=3Dparameter>>=20

doesn't work

Any ideas appreciated



 

Thanks,

John

From trwww at sbcglobal.net  Fri Feb 29 07:44:22 2008
From: trwww at sbcglobal.net (Todd W)
Date: Fri Feb 29 07:44:19 2008
Subject: [cgiapp] ValidateRM and dynamic content
References: <788CE35B4DF22443A7AA542796706AB501692F23@liex2.liaison-intl.com>
Message-ID: <005501c87ad0$cf577260$7201a8c0@trwlapgateway>


From: "John Spooner" <jspooner@liaison-intl.com>

> I am using HTML::Template and CGI::Application::Plugin::ValidateRM.
> Page content is generated dynamically which works fine until a
> validation error occurs.  Unfortunately <err_<TMPL_VAR field_name>> is
> not valid H::T.
>
> In perusing the C::A email archives I see that the same issue has been
> brought up before (almost 3 years ago, but at least I know others have
> suffered the same fate).  Unfortunately there was no documented
> resolution.  Does anyone have any advice?

I dont have anything for you other than you have reached the designed limits 
of H::T.

My advice is to switch to TT (pretty easy, esp since you are already using 
CGI::App).

Todd W.

From unrtst at gmail.com  Fri Feb 29 19:17:24 2008
From: unrtst at gmail.com (Joshua Miller)
Date: Fri Feb 29 19:17:26 2008
Subject: [cgiapp] ValidateRM and dynamic content
In-Reply-To: <005501c87ad0$cf577260$7201a8c0@trwlapgateway>
References: <788CE35B4DF22443A7AA542796706AB501692F23@liex2.liaison-intl.com>
	<005501c87ad0$cf577260$7201a8c0@trwlapgateway>
Message-ID: <1b9c12d0802291617q5dbd2a92h5897562180367118@mail.gmail.com>

On Fri, Feb 29, 2008 at 7:44 AM, Todd W <trwww@sbcglobal.net> wrote:

>
> From: "John Spooner" <jspooner@liaison-intl.com>
>
> > I am using HTML::Template and CGI::Application::Plugin::ValidateRM.
> > Page content is generated dynamically which works fine until a
> > validation error occurs.  Unfortunately <err_<TMPL_VAR field_name>> is
> > not valid H::T.
> >
> > In perusing the C::A email archives I see that the same issue has been
> > brought up before (almost 3 years ago, but at least I know others have
> > suffered the same fate).  Unfortunately there was no documented
> > resolution.  Does anyone have any advice?
>
> I dont have anything for you other than you have reached the designed
> limits
> of H::T.
>
> My advice is to switch to TT (pretty easy, esp since you are already using
> CGI::App).
>


I'm currious... how would that work under TT? Wouldn't the dynamic field
names cause the same issues for CAP:ValidateRM?
From azfuller at gmail.com  Fri Feb 29 19:45:46 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Fri Feb 29 19:45:50 2008
Subject: [cgiapp] ValidateRM and dynamic content
In-Reply-To: <788CE35B4DF22443A7AA542796706AB501692F23@liex2.liaison-intl.com>
References: <788CE35B4DF22443A7AA542796706AB501692F23@liex2.liaison-intl.com>
Message-ID: <d69cc4a60802291645y7ff9b93dh78797e045919395a@mail.gmail.com>

>  I am using HTML::Template and CGI::Application::Plugin::ValidateRM.
>  Page content is generated dynamically which works fine until a
>  validation error occurs.  Unfortunately <err_<TMPL_VAR field_name>> is
>  not valid H::T.

If your form fieldnames are dynamic I can think of a couple of options.

1. Use H::T's "filter" feature to preprocess the template and make
some dynamic changes to it.

2. Read the template yourself, dynamically add to it, and use
load_tmpl's ability to load from a scalar.

3. Dynamically create an included file before loading the template.

4. Don't use dynamic form fieldnames. If you need to distinguish
between how a form is used, set a hidden field value to essentially
categorize how this form is different than another form.

Maybe I'm missing something about why you're using dynamic field names.

Mark
From ceeshek at gmail.com  Sun Mar  2 08:22:52 2008
From: ceeshek at gmail.com (Cees Hek)
Date: Sun Mar  2 08:22:53 2008
Subject: [cgiapp] some plugin updates (finally)
Message-ID: <fd8e28ef0803020522i679d6f48v662a0d60f0dbd397@mail.gmail.com>

Hi All,

I finally got off my ass and updated some of my plugins.  There were a
slew of feature requests, and fixes that have been sitting in my queue
for ages, and I finally forced myself to sit down and try and get up
to date again.

New version of the following plugins are on their way to your nearest
CPAN mirror as we speak:

CGI::Application::Plugin::Authorization
CGI::Application::Plugin::LogDispatch
CGI::Application::Plugin::Redirect
CGI::Application::Plugin::Session
CGI::Application::Plugin::TT

There are still some pending updates on
CGI::Application::Plugin::Authentication that I didn't quite get to...

There is a good chance that I have missed something along the way in
these latest versions.  If I have, I apologize.  Lodge your
bug/patch/request in rt.cpan.org instead of emailing me directly as an
email will invariably get misplaced.

Cheers,

Cees
From cgi-application at howlingfrog.com  Mon Mar  3 15:22:01 2008
From: cgi-application at howlingfrog.com (Graham TerMarsch)
Date: Mon Mar  3 15:22:05 2008
Subject: [cgiapp] some plugin updates (finally)
In-Reply-To: <fd8e28ef0803020522i679d6f48v662a0d60f0dbd397@mail.gmail.com>
References: <fd8e28ef0803020522i679d6f48v662a0d60f0dbd397@mail.gmail.com>
Message-ID: <200803031222.01950.cgi-application@howlingfrog.com>

On Sunday 02 March 2008 5:22 am, Cees Hek wrote:
> I finally got off my ass and updated some of my plugins.  There were a
> slew of feature requests, and fixes that have been sitting in my queue
> for ages, and I finally forced myself to sit down and try and get up
> to date again.

Cees, you -ROCK-. :)

I've been anxiously awaiting some of these releases as they include some bits 
that I'm particularly fond of (gee, maybe because I wrote them to scratch my 
own itch?)

Thanks for the update!!!

-- 
Graham TerMarsch
Howling Frog Internet Development, Inc.
From lackhoff at zbmed.uni-koeln.de  Tue Mar  4 09:39:25 2008
From: lackhoff at zbmed.uni-koeln.de (Michael Lackhoff)
Date: Tue Mar  4 09:39:30 2008
Subject: [cgiapp] Test Failures with CGI::Application::Plugin::TT
Message-ID: <47CD6D2D.29220.12810A9@lackhoff.zbmed.uni-koeln.de>

Hello Cees,

thanks for the new versions of your plugins. Everything looks fine with 
a tiny exception:

t/09_precompile_dir......1/6
#   Failed test 'file is cached'
#   at t/09_precompile_dir.t line 31.
#          got: 'C:\.cpan\build\CGI-Application-Plugin-TT-
1.04\t\include1\TestAppIncludePath/test_mode.tmpl'
#     expected: 'C:\.cpan\build\CGI-Application-Plugin-TT-
1.04\t\include1\TestAppIncludePath\test_mode.tmpl'

#   Failed test 'file is cached'
#   at t/09_precompile_dir.t line 31.
#          got: 'C:\.cpan\build\CGI-Application-Plugin-TT-
1.04\t\include1\TestAppIncludePath/test_mode.tmpl'
#     expected: 'C:\.cpan\build\CGI-Application-Plugin-TT-
1.04\t\include1\TestAppIncludePath\test_mode.tmpl'

#   Failed test 'file is cached'
#   at t/09_precompile_dir.t line 31.
#          got: undef
#     expected: 'C:\.cpan\build\CGI-Application-Plugin-TT-
1.04\t\include1\TestAppIncludePath\test_mode.tmpl'
# Looks like you failed 3 tests of 6.
t/09_precompile_dir...... Dubious, test returned 3 (wstat 768, 0x300)
 Failed 3/6 subtests

It looks as if the first two are harmless (just one slash/backslash 
mixed up) but the third error looks like something is really going 
wrong.
As you can guess from the "C:\..." everything is under Windows 2000, 
Perl is a self-compiled 5.8.8 with VC6 from the official sources (not 
Activestate).

Any ideas?
-Michael

From cgi-application at howlingfrog.com  Tue Mar  4 15:50:30 2008
From: cgi-application at howlingfrog.com (Graham TerMarsch)
Date: Tue Mar  4 15:50:38 2008
Subject: [cgiapp] Q: Authz, but only when user is Authenticated...
Message-ID: <200803041250.31693.cgi-application@howlingfrog.com>

With the recent release of CAP::Authz 0.07, I've started going back through my 
existing apps and updating them to use the "authz_runmodes()" instead of my 
custom Authz plugins which did something similar.

While doing this, however, I've run into a scenario that I thought I'd ask for 
some input on...

In most of the apps I'm working with right now, Authz is only useful if I've 
got an Authenticated user; if the user hasn't logged in then there's no point 
in even checking for Authz as I really want to show them a login page first.  
My custom Authz plugins used to check this for me, but I'm trying to find a 
simpler way to get this working with the new version of CAP::Authz so I can 
pitch my custom code.

So, I load up CAP::Authen and CAP::Authz in my App superclass and the prerun 
hooks get invoked in order (authen first, then authz).  However... if they 
both fail (user isn't logged in, so I obviously fail authz), CAP::Authz 
calls "prerun_mode()" last and overrides the rm that was set by CAP::Authen 
to trigger the login screen.

I've got a few possible ideas for working around this, but wanted to find out 
what others are doing...

1) Load CAP::Authz first.  That way, even if Authz fails, CAP::Authen would be 
the last one to call "prerun_mode()" and the user would get shown the login 
page.  This works, but feels counter-intuitive; I'm always thinking that I 
want Authen to run first so I load that plugin first.

2) Add a new "REQUIRES_AUTHEN" option to CAP::Authz, so that if its unable to 
even figure out what the username is then it doesn't even bother doing an 
Authz check.

What are you guys doing when you want similar behaviour?

------

FWIW, some minimal code to show my setup would go like this...

  class MY::App;
  use base qw(CGI::Application);
  use CGI::Application::Plugin::Authentication;
  use CGI::Application::Plugin::Authorization;
  sub cgiapp_init {
    my $self = shift;
    $self->authen->config( ... );
    $self->authz->config( ... );
  }

  class MY::DerivedApp;
  use base qw(MY::App);
  sub setup {
    my $self = shift;
    $self->authen->protected_runmodes( ':all' );
    $self->authz->authz_runmodes( ':all' => 'admin' );
  }

Gist of the setup is that the superclass sets up the global Authen/Authz 
config and the drivers, while each derived app then sets up the list of 
Authen protected runmodes and the Authz requirements for the modes.

-- 
Graham TerMarsch
From fluffymike at googlemail.com  Wed Mar  5 06:47:51 2008
From: fluffymike at googlemail.com (Mike Tonks)
Date: Wed Mar  5 06:47:53 2008
Subject: [cgiapp] Persistence
In-Reply-To: <47AC7420.7010107@plusthree.com>
References: <200802031114.29209@centrum.cz>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
	<2428c0380802061622u50ae1267kd17adfdac937e341@mail.gmail.com>
	<47AC7420.7010107@plusthree.com>
Message-ID: <727692630803050347j6eb3a1b7oda428ac055031852@mail.gmail.com>

I've just come back to this thread as I'm just about to alter the
session handling in tha app that I'm working on.  It currently uses
the url method, which I plan to replace.

I'm struggling to accept the form method, because as you say no more
<a href="myapp.cgi?rm=next"> - unless of course we use javascript.

Now I like the old links, so cookies seems like a no brainer to me.
Can anyone explain why the form method is better and how you implement
links?

Mike Tonks
Developer - BookBank.com

On 08/02/2008, Michael Peters <mpeters@plusthree.com> wrote:
> Stephen Carville wrote:
>
>  > Seems to me it makes more sense to embed the session ID or any other
>  > tracking as hidden variables in a form and send it back as a POST.
>
>
> This assumes then that every request you make is now a post request. Which means
>  not more <a> links, just forms. And this also breaks REST style apps (and really
>  anything that tries to have meaningful HTTP semantics) since POST requests are
>  for things that could change the data server-side and GET requests are for
>  anything that won't (idempotent). In this day and age you really have to expect
>  your users to use cookies. I can understand people not wanting to be tracked
>  long term, but why should anyone object to memory-only cookies?
>
>
>  --
>
> Michael Peters
>  Developer
>  Plus Three, LP
>
>
From azfuller at gmail.com  Wed Mar  5 11:20:19 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Wed Mar  5 11:20:21 2008
Subject: [cgiapp] Persistence
In-Reply-To: <727692630803050347j6eb3a1b7oda428ac055031852@mail.gmail.com>
References: <200802031114.29209@centrum.cz>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
	<2428c0380802061622u50ae1267kd17adfdac937e341@mail.gmail.com>
	<47AC7420.7010107@plusthree.com>
	<727692630803050347j6eb3a1b7oda428ac055031852@mail.gmail.com>
Message-ID: <d69cc4a60803050820t19026ddcgd3974a0a26d7d099@mail.gmail.com>

On Wed, Mar 5, 2008 at 4:47 AM, Mike Tonks <fluffymike@googlemail.com> wrote:
>
>  I'm struggling to accept the form method, because as you say no more
>  <a href="myapp.cgi?rm=next"> - unless of course we use javascript.
>
>  Now I like the old links, so cookies seems like a no brainer to me.
>  Can anyone explain why the form method is better and how you implement
>  links?

It sounds like you're changing from "a href" links to form-submit
actions? Why do you feel this is better? I got the impression from the
earlier discussion that form submission is better if data is being
changed. But, traditional links are better for things that don't
change anything, like navigation.

What was said earlier is that you wouldn't want to pass the sessionID
as a parameter on a URL. You could put it in a form (hidden field) to
solve some of the problems with people emailing a URL to others. But,
using a form forces you to use form submission when it's not the best
choice. If you use a cookie to pass the sessionID you can use URLs or
forms depending on which makes sense.

I've forgotten everything that was said earlier. Let me know if I
overlooked something important.

Also, not to confuse you, but you don't have to use "rm=" as the
runmode. If all your pages have a forward and backward feature, you
could use "direction=forward" or "page=5" or "page=advance". You can
name your runmode variable anything you want. But, if you're just
starting out, following tutorials you've read, it might be easier to
use the "rm" convention. (If you want to get really fancy you can name
your links like myapp.cgi/book_name/next and either parse the path in
your setup or use plugin::actionDispatch to do it for you
automatically).

Mark
From sigzero at gmail.com  Wed Mar  5 16:54:40 2008
From: sigzero at gmail.com (Robert Hicks)
Date: Wed Mar  5 16:55:14 2008
Subject: [cgiapp] URL rewriting...
Message-ID: <fqn4rc$72u$1@ger.gmane.org>

I haven't a clue on this one. I do the standard CA thing with page names:

?rm=home
?rm=contact

How do I do a URL re-write that makes the first one /home/ and the 
second one /contact/ ?

Pointers would help...you don't have to give me the whole answer. I like 
to learn.  :-)

Robert

From mpeters at plusthree.com  Wed Mar  5 16:55:14 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Wed Mar  5 16:58:05 2008
Subject: [cgiapp] URL rewriting...
In-Reply-To: <fqn4rc$72u$1@ger.gmane.org>
References: <fqn4rc$72u$1@ger.gmane.org>
Message-ID: <47CF16C2.4030107@plusthree.com>

Robert Hicks wrote:
> I haven't a clue on this one. I do the standard CA thing with page names:
> 
> ?rm=home
> ?rm=contact
> 
> How do I do a URL re-write that makes the first one /home/ and the
> second one /contact/ ?

CGI::Application::Dispatch. Not only will it let do URLs like that, but it will
also help you combine multiple app modules into a single app.

If your application module is named MyApp::Stuff then you can do urls like

  /stuff/home
  /stuff/contact

Very easily.

-- 
Michael Peters
Plus Three, LP

From trwww at sbcglobal.net  Thu Mar  6 14:19:32 2008
From: trwww at sbcglobal.net (Todd W)
Date: Thu Mar  6 14:19:35 2008
Subject: [Bulk] Re: [cgiapp] ValidateRM and dynamic content
References: <788CE35B4DF22443A7AA542796706AB501692F23@liex2.liaison-intl.com><005501c87ad0$cf577260$7201a8c0@trwlapgateway>
	<1b9c12d0802291617q5dbd2a92h5897562180367118@mail.gmail.com>
Message-ID: <009c01c87fbf$028e9940$7201a8c0@trwlapgateway>


From: "Joshua Miller" <unrtst@gmail.com>
> On Fri, Feb 29, 2008 at 7:44 AM, Todd W <trwww@sbcglobal.net> wrote:
>> From: "John Spooner" <jspooner@liaison-intl.com>
>>
>> > I am using HTML::Template and CGI::Application::Plugin::ValidateRM.
>> > Page content is generated dynamically which works fine until a
>> > validation error occurs.  Unfortunately <err_<TMPL_VAR field_name>> is
>> > not valid H::T.
>> >
>> > In perusing the C::A email archives I see that the same issue has been
>> > brought up before (almost 3 years ago, but at least I know others have
>> > suffered the same fate).  Unfortunately there was no documented
>> > resolution.  Does anyone have any advice?
>>
>> I dont have anything for you other than you have reached the designed
>> limits
>> of H::T.
>>
>> My advice is to switch to TT (pretty easy, esp since you are already 
>> using
>> CGI::App).
>>
> I'm currious... how would that work under TT? Wouldn't the dynamic field
> names cause the same issues for CAP:ValidateRM?

Just pure guesses here at what is trying to be accomplished, but I'm 
assuming that the form is being built dynamically, hence the need to use a 
variable to do lookups in to the validator (looking at the OP again, though, 
I think my assumption is incorrect. It looks like he just needs a <TMPL_IF 
NAME="err_field_name">...</TMPL_IF>), then I'd just use the same 
hash/array/object(s) that was used to build the dynamic form to both build 
the DFV profile and look up error messages in the template.

trwww

From stephen.carville at gmail.com  Thu Mar  6 16:15:57 2008
From: stephen.carville at gmail.com (Stephen Carville)
Date: Thu Mar  6 16:16:01 2008
Subject: [cgiapp] Persistence
In-Reply-To: <47AC7420.7010107@plusthree.com>
References: <200802031114.29209@centrum.cz>
	<001c01c8673e$d233c2e0$6401a8c0@lousmaster>
	<010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net>
	<1202246282.27200.94.camel@zoe.savage.net.au>
	<039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net>
	<1202334445.27200.103.camel@zoe.savage.net.au>
	<d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com>
	<45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz>
	<2428c0380802061622u50ae1267kd17adfdac937e341@mail.gmail.com>
	<47AC7420.7010107@plusthree.com>
Message-ID: <2428c0380803061315j3c22e70cwc3440e7c2ce436b7@mail.gmail.com>

On Fri, Feb 8, 2008 at 7:24 AM, Michael Peters <mpeters@plusthree.com> wrote:
> Stephen Carville wrote:
>
>  > Seems to me it makes more sense to embed the session ID or any other
>  > tracking as hidden variables in a form and send it back as a POST.
>
>  This assumes then that every request you make is now a post request. Which means
>  not more <a> links, just forms. And this also breaks REST style apps (and really
>  anything that tries to have meaningful HTTP semantics) since POST requests are
>  for things that could change the data server-side and GET requests are for
>  anything that won't (idempotent). In this day and age you really have to expect
>  your users to use cookies. I can understand people not wanting to be tracked
>  long term, but why should anyone object to memory-only cookies?

I see your point.  I was thinking about a sequence of forms where
catching a replay is important.  Like changing passwords or entering
financial information.  Obviously the normally stateless HTTP
documents don't need that.

--
Stephen Carville
From lhernsen1015 at wowway.com  Fri Mar  7 00:06:12 2008
From: lhernsen1015 at wowway.com (Lou Hernsen)
Date: Fri Mar  7 00:10:23 2008
Subject: [cgiapp] Help with m// needed
References: <200802031114.29209@centrum.cz><001c01c8673e$d233c2e0$6401a8c0@lousmaster><010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net><1202246282.27200.94.camel@zoe.savage.net.au><039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net><1202334445.27200.103.camel@zoe.savage.net.au><d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com><45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz><2428c0380802061622u50ae1267kd17adfdac937e341@mail.gmail.com><47AC7420.7010107@plusthree.com>
	<2428c0380803061315j3c22e70cwc3440e7c2ce436b7@mail.gmail.com>
Message-ID: <00f001c88011$11dc2aa0$6401a8c0@lousmaster>

I am trying to match
French
in the string
French:6:47
The code is

if ($PFile{Allied} =~ m/$Port/)

and the actual vars would be

if (French =~ m/French:6:47/)

and there should be a match!!!!
but 

but it doesn't work.. and I don't see why.... 
I have used m// before the never had this problem...

Help? thanks
Lou
Perl is my HOBBY... just something to keep my mind sharp.
From barry.moore at genetics.utah.edu  Fri Mar  7 00:19:03 2008
From: barry.moore at genetics.utah.edu (Barry Moore)
Date: Fri Mar  7 00:19:12 2008
Subject: [cgiapp] Help with m// needed
In-Reply-To: <00f001c88011$11dc2aa0$6401a8c0@lousmaster>
References: <200802031114.29209@centrum.cz><001c01c8673e$d233c2e0$6401a8c0@lousmaster><010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net><1202246282.27200.94.camel@zoe.savage.net.au><039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net><1202334445.27200.103.camel@zoe.savage.net.au><d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com><45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz><2428c0380802061622u50ae1267kd17adfdac937e341@mail.gmail.com><47AC7420.7010107@plusthree.com>
	<2428c0380803061315j3c22e70cwc3440e7c2ce436b7@mail.gmail.com>
	<00f001c88011$11dc2aa0$6401a8c0@lousmaster>
Message-ID: <88BBDBAA-957C-4749-B3BE-F9E8B8409801@genetics.utah.edu>

Hi Lou,

You've got your variables around backwards. For that to match you need:

$regexp = 'French';
$variable = 'French:6:47';

if ($variable =~ /$regexp/) {
	print "This works\n";
}

BTW, this mailing list is specifically for CGI::Application issues,  
and it's members will generally refer you to something like Perl  
Monks for general perl questions like this one.

Barry


On Mar 6, 2008, at 10:06 PM, Lou Hernsen wrote:

> I am trying to match
> French
> in the string
> French:6:47
> The code is
>
> if ($PFile{Allied} =~ m/$Port/)
>
> and the actual vars would be
>
> if (French =~ m/French:6:47/)
>
> and there should be a match!!!!
> but
>
> but it doesn't work.. and I don't see why....
> I have used m// before the never had this problem...
>
> Help? thanks
> Lou
> Perl is my HOBBY... just something to keep my mind sharp.
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>

From lhernsen1015 at wowway.com  Fri Mar  7 00:19:37 2008
From: lhernsen1015 at wowway.com (Lou Hernsen)
Date: Fri Mar  7 00:23:37 2008
Subject: [cgiapp] Help with m// needed
References: <200802031114.29209@centrum.cz><001c01c8673e$d233c2e0$6401a8c0@lousmaster><010701c867e4$0ff99b40$06fe000a@gboffice.gorillabox.net><1202246282.27200.94.camel@zoe.savage.net.au><039401c86898$95ec7b00$06fe000a@gboffice.gorillabox.net><1202334445.27200.103.camel@zoe.savage.net.au><d69cc4a60802061411x70181aa3g23c1e6b2cd2d939b@mail.gmail.com><45189.210.54.245.44.1202341143.squirrel@mail.redbone.co.nz><2428c0380802061622u50ae1267kd17adfdac937e341@mail.gmail.com><47AC7420.7010107@plusthree.com><2428c0380803061315j3c22e70cwc3440e7c2ce436b7@mail.gmail.com><00f001c88011$11dc2aa0$6401a8c0@lousmaster>
	<88BBDBAA-957C-4749-B3BE-F9E8B8409801@genetics.utah.edu>
Message-ID: <010c01c88012$eba53aa0$6401a8c0@lousmaster>

Doooo!
I slapped myself in the forehead...
Thanks
I must be sleepy...

I used to be on anyother list more appropreate for this type of question,
but there is this guy "R.S." who is so rude.. and its a beginners list! ..
but you are correct and I do appologize

Lou


----- Original Message ----- 
From: "Barry Moore" <barry.moore@genetics.utah.edu>
To: "CGI Application" <cgiapp@lists.erlbaum.net>
Sent: Friday, March 07, 2008 12:19 AM
Subject: Re: [cgiapp] Help with m// needed


> Hi Lou,
>
> You've got your variables around backwards. For that to match you need:
>
> $regexp = 'French';
> $variable = 'French:6:47';
>
> if ($variable =~ /$regexp/) {
> print "This works\n";
> }
>
> BTW, this mailing list is specifically for CGI::Application issues,
> and it's members will generally refer you to something like Perl
> Monks for general perl questions like this one.
>
> Barry
>
>
> On Mar 6, 2008, at 10:06 PM, Lou Hernsen wrote:
>
> > I am trying to match
> > French
> > in the string
> > French:6:47
> > The code is
> >
> > if ($PFile{Allied} =~ m/$Port/)
> >
> > and the actual vars would be
> >
> > if (French =~ m/French:6:47/)
> >
> > and there should be a match!!!!
> > but
> >
> > but it doesn't work.. and I don't see why....
> > I have used m// before the never had this problem...
> >
> > Help? thanks
> > Lou
> > Perl is my HOBBY... just something to keep my mind sharp.
> >
> > #####  CGI::Application community mailing list  ################
> > ##                                                            ##
> > ##  To unsubscribe, or change your message delivery options,  ##
> > ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> > ##                                                            ##
> > ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> > ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> > ##                                                            ##
> > ################################################################
> >
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.21.6/1315 - Release Date: 3/6/08
9:07 AM
>
>

From Todd_Ross at mgic.com  Fri Mar  7 10:34:00 2008
From: Todd_Ross at mgic.com (Todd Ross)
Date: Fri Mar  7 10:34:18 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
Message-ID: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>

I've seen quite a few posts on this list concerning 
CGI::Application::Dispatch.  I'd like to try it out.  Installing it, 
however, seems to be a problem.  Since there is no README or INSTALL 
included in the archive, I'm following the normal Makefile.PL (or 
Build.PL) procedures.

[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> ls
Build.PL     Changes      lib          Makefile.PL  MANIFEST     META.yml  
  t            TODO
[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl Makefile.PL
This module can optionally use Apache::Test to test the mod_perl 
functionality.
Undefined subroutine &ExtUtils::MakeMaker::prompt called at Makefile.PL 
line 31, <DATA> line 547.
[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl Build.PL
Can't locate object method "new" via package "Module::Build" (perhaps you 
forgot to load "Module::Build"?) at Build.PL line 2.

Is there a known problem with CGI::Application::Dispatch?  How have others 
installed this?

Since its complaining about not finding a MakeMaker sub, the version of 
MakeMaker I'm using is probably relevant:

[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl 
-MExtUtils::MakeMaker -e 'print "$ExtUtils::MakeMaker::VERSION\n"'
6.30

The Perl version is also probably relevant:

[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl -v

This is perl, v5.8.8 built for sun4-solaris

<snip>

I've installed 100s of CPAN modules using these procedures with this build 
of Perl, so I'm comfortable with my environment.

Todd
From azfuller at gmail.com  Fri Mar  7 11:04:26 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Fri Mar  7 11:04:34 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
In-Reply-To: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>
References: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>
Message-ID: <d69cc4a60803070804j4459b7akaa91eb18bab6b3cf@mail.gmail.com>

On Fri, Mar 7, 2008 at 8:34 AM, Todd Ross <Todd_Ross@mgic.com> wrote:
> I've seen quite a few posts on this list concerning
>  CGI::Application::Dispatch.

Was it Dispatch or Plugin::ActionDispatch?

http://search.cpan.org/perldoc?CGI%3A%3AApplication%3A%3APlugin%3A%3AActionDispatch

I know I mentioned something recently about "dispatch." But, I was
talking about the plugin. I don't understand how the two differ. There
might be a reason to use the non-plugin Dispatch.

Mark
From ron at savage.net.au  Fri Mar  7 17:02:34 2008
From: ron at savage.net.au (Ron Savage)
Date: Fri Mar  7 17:00:13 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
In-Reply-To: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>
References: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>
Message-ID: <1204927354.7068.31.camel@zoe.savage.net.au>

Hi Todd

On Fri, 2008-03-07 at 09:34 -0600, Todd Ross wrote:
> I've seen quite a few posts on this list concerning 
> CGI::Application::Dispatch.  I'd like to try it out.  Installing it, 
> however, seems to be a problem.  Since there is no README or INSTALL 
> included in the archive, I'm following the normal Makefile.PL (or 
> Build.PL) procedures.

It's a marvellous package. Highly recommended.

> [me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> ls
> Build.PL     Changes      lib          Makefile.PL  MANIFEST     META.yml  
>   t            TODO

I just reinstalled this same version. See below.

> [me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl Makefile.PL
> This module can optionally use Apache::Test to test the mod_perl 
> functionality.
> Undefined subroutine &ExtUtils::MakeMaker::prompt called at Makefile.PL 
> line 31, <DATA> line 547.
 
Makefile.PL failed for me when trying to automatically install Apache::Test.
Forget Makefile.PL.

> [me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl Build.PL
> Can't locate object method "new" via package "Module::Build" (perhaps you 
> forgot to load "Module::Build"?) at Build.PL line 2.

Build.PL recommends Apache::Test so I installed it with:
shell> perl -MCPAN -e 'install Apache::Test'

After that, Build.PL worked perfectly.

Do you have Module::Build installed? If not, install it as I did with
Apache::Test. Do Apache::Test too, of course. Then try again, and tell
us what happens.

-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ddmails at web.de  Sat Mar  8 05:05:26 2008
From: ddmails at web.de (Torsten)
Date: Sat Mar  8 05:06:13 2008
Subject: [cgiapp] cgiapp with Net::Server
Message-ID: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>

Hi,

i try to use a standalone cgiapp using Net::Server.

Most time it works great, but sometimes it detects a wrong runmode.

I attached a little test application showing the problem. It simply
switches between two runmodes. If you click a while then about every 10
clicks the same runmode is used.

You can start ./httpd and connect with browser
http://localhost:8080/test/

Any Ideas?

Thanks a lot
  Torsten
From azfuller at gmail.com  Sat Mar  8 11:30:31 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sat Mar  8 11:39:18 2008
Subject: [cgiapp] cgiapp with Net::Server
In-Reply-To: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
References: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
Message-ID: <d69cc4a60803080830h34602a51rbc7e0c8047b3955a@mail.gmail.com>

On Sat, Mar 8, 2008 at 3:05 AM, Torsten <ddmails@web.de> wrote:
>
>  I attached a little test application showing the problem.

I don't think the mailing list accepts/distributes attachments. If you
want to email it to me directly I can look at it.

Mark
From lecar_red at yahoo.com  Sat Mar  8 12:17:12 2008
From: lecar_red at yahoo.com (Lee Carmichael)
Date: Sat Mar  8 12:17:45 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
Message-ID: <165865.93928.qm@web31405.mail.mud.yahoo.com>

Hello Todd, 


I had the same issues, see bug: http://rt.cpan.org/Public/Bug/Display.html?id=33498


I found that I needed to patch a Build.PL and Makefile.PL when Apache::Test wasn't installed.


There are patches attached to the bug, give them a try. I'm pretty confident they will work (that probably means something is mucked up with them :)


Good Luck,


Lee

----- Original Message ----
From: Todd Ross <Todd_Ross@mgic.com>
To: CGI Application <cgiapp@lists.erlbaum.net>
Sent: Friday, March 7, 2008 9:34:00 AM
Subject: [cgiapp] CGI::Application::Dispatch Install Issues

I've seen quite a few posts on this list concerning 
CGI::Application::Dispatch.  I'd like to try it out.  Installing it, 
however, seems to be a problem.  Since there is no README or INSTALL 
included in the archive, I'm following the normal Makefile.PL (or 
Build.PL) procedures.

[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> ls
Build.PL     Changes      lib          Makefile.PL  MANIFEST     META.yml  
  t            TODO
[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl Makefile.PL
This module can optionally use Apache::Test to test the mod_perl 
functionality.
Undefined subroutine &ExtUtils::MakeMaker::prompt called at Makefile.PL 
line 31, <DATA> line 547.
[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl Build.PL
Can't locate object method "new" via package "Module::Build" (perhaps you 
forgot to load "Module::Build"?) at Build.PL line 2.

Is there a known problem with CGI::Application::Dispatch?  How have others 
installed this?

Since its complaining about not finding a MakeMaker sub, the version of 
MakeMaker I'm using is probably relevant:

[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl 
-MExtUtils::MakeMaker -e 'print "$ExtUtils::MakeMaker::VERSION\n"'
6.30

The Perl version is also probably relevant:

[me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl -v

This is perl, v5.8.8 built for sun4-solaris

<snip>

I've installed 100s of CPAN modules using these procedures with this build 
of Perl, so I'm comfortable with my environment.

Todd

#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################





From mpeters at plusthree.com  Sat Mar  8 12:49:07 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Sat Mar  8 12:51:50 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
In-Reply-To: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>
References: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>
Message-ID: <47D2D193.8010605@plusthree.com>

Todd Ross wrote:

> [me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl Makefile.PL
> This module can optionally use Apache::Test to test the mod_perl 
> functionality.
> Undefined subroutine &ExtUtils::MakeMaker::prompt called at Makefile.PL 
> line 31, <DATA> line 547.

I'm curious about this one. I'm not sure which version of ExtUtils::MakeMaker
added prompt (it's in at least 6.31, but I don't know about 6.30). It works just
fine for me.

I am trying to be smarter than the average Makefile.PL, but I just seem to be
getting more trouble then it's work at this point. I'll probably just go back to
being dumb and not run the Apache/mod_perl tests unless the person already have
Apache::Test installed.

> [me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl Build.PL
> Can't locate object method "new" via package "Module::Build" (perhaps you 
> forgot to load "Module::Build"?) at Build.PL line 2.

You need to install Module::Build using CPAN.

> Is there a known problem with CGI::Application::Dispatch?  How have others 
> installed this?
> 
> Since its complaining about not finding a MakeMaker sub, the version of 
> MakeMaker I'm using is probably relevant:
> 
> [me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl 
> -MExtUtils::MakeMaker -e 'print "$ExtUtils::MakeMaker::VERSION\n"'
> 6.30

Try upgrading your ExtUtils::MakeMaker.

> The Perl version is also probably relevant:
> 
> [me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]> perl -v
> 
> This is perl, v5.8.8 built for sun4-solaris
> 
> <snip>
> 
> I've installed 100s of CPAN modules using these procedures with this build 
> of Perl, so I'm comfortable with my environment.

using the command line to install perl modules is so 2000 :) Have you tried the
CPAN shell?

-- 
Michael Peters
Plus Three, LP

From mpeters at plusthree.com  Sat Mar  8 13:26:42 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Sat Mar  8 13:29:27 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
In-Reply-To: <47D2D193.8010605@plusthree.com>
References: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>
	<47D2D193.8010605@plusthree.com>
Message-ID: <47D2DA62.3070504@plusthree.com>

Michael Peters wrote:

> I am trying to be smarter than the average Makefile.PL, but I just seem to be
> getting more trouble then it's work at this point. I'll probably just go back to
> being dumb and not run the Apache/mod_perl tests unless the person already have
> Apache::Test installed.

Ok, not instead of trying to use the toolchain to install Module::Build and then
Apache::Test (if you answered yes at the prompt) I'm just going to be really
dumb. If you have Apache::Test on your machine I will use it and run the
mod_perl tests as well as the CGI ones. Else I won't. And since apparently not
everyone has upgraded their toolchain to include Module::Build I'll include a
normal Makefile.PL in the distribution.

I do have to say though that it really bothers me to have to make my modules
work for people who don't want to bother with upgrading their toolchain :)

-- 
Michael Peters
Plus Three, LP

From mpeters at plusthree.com  Sat Mar  8 13:29:10 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Sat Mar  8 13:31:54 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
In-Reply-To: <47D2DA62.3070504@plusthree.com>
References: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>
	<47D2D193.8010605@plusthree.com> <47D2DA62.3070504@plusthree.com>
Message-ID: <47D2DAF6.9010104@plusthree.com>

Michael Peters wrote:

> Ok, not instead of trying to use the toolchain to install Module::Build and then
> Apache::Test (if you answered yes at the prompt) I'm just going to be really
> dumb. If you have Apache::Test on your machine I will use it and run the
> mod_perl tests as well as the CGI ones. Else I won't. And since apparently not
> everyone has upgraded their toolchain to include Module::Build I'll include a
> normal Makefile.PL in the distribution.

I forgot to mention that I just uploaded CGI::Application::Dispatch 2.13_01 to
CPAN. Since it's a dev release it won't be installable via the CPAN shell, so if
you want to see if it fixes your install issues, then you'll have to try it out
by hand.

-- 
Michael Peters
Plus Three, LP

From mark at stosberg.com  Sat Mar  8 16:31:53 2008
From: mark at stosberg.com (Mark Stosberg)
Date: Sat Mar  8 17:35:05 2008
Subject: [cgiapp] Re: ValidateRM and dynamic content
In-Reply-To: <788CE35B4DF22443A7AA542796706AB501692F23@liex2.liaison-intl.com>
References: <788CE35B4DF22443A7AA542796706AB501692F23@liex2.liaison-intl.com>
Message-ID: <alpine.DEB.1.00.0803081630340.6992@mat>

>
> I am using HTML::Template and CGI::Application::Plugin::ValidateRM.
> Page content is generated dynamically which works fine until a
> validation error occurs.  Unfortunately <err_<TMPL_VAR field_name>> is
> not valid H::T.

Could you provide a more complete example? I have been using ValidateRM
and H::T with complex websites for years and haven't gotten stuck here.
I suspect there's another way to accomplish your goal while still using
sing these tools.

     Mark

-- 
http://mark.stosberg.com/


From ron at savage.net.au  Sat Mar  8 18:04:48 2008
From: ron at savage.net.au (Ron Savage)
Date: Sat Mar  8 18:02:21 2008
Subject: [cgiapp] cgiapp with Net::Server
In-Reply-To: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
References: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
Message-ID: <1205017488.7068.46.camel@zoe.savage.net.au>

Hi Torsten

> I attached a little test application showing the problem. It simply

Hmmmm. Odd. My email client - Evolution - shows a paperclip suggesting
that there is an attachment, but I can't otherwise see it.

I suggest you upload your demo to your web site and send the url in an
email msg to the list.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ddmails at web.de  Sun Mar  9 09:38:17 2008
From: ddmails at web.de (Torsten)
Date: Sun Mar  9 09:38:25 2008
Subject: [cgiapp] cgiapp with Net::Server
In-Reply-To: <1205017488.7068.46.camel@zoe.savage.net.au>
References: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
	<1205017488.7068.46.camel@zoe.savage.net.au>
Message-ID: <20080309143817.572da005@apfeltasche.neo2k.homeip.net>

Hi Ron,

you are right, the mailing list removed the attachment.

I put it here:

http://www.tb-solutions.biz/stuff/http_test.tgz

  Torsten


Am Sun, 09 Mar 2008 10:04:48 +1100
schrieb Ron Savage <ron@savage.net.au>:

> Hi Torsten
> 
> > I attached a little test application showing the problem. It simply
> 
> Hmmmm. Odd. My email client - Evolution - shows a paperclip suggesting
> that there is an attachment, but I can't otherwise see it.
> 
> I suggest you upload your demo to your web site and send the url in an
> email msg to the list.
From azfuller at gmail.com  Sun Mar  9 10:07:10 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sun Mar  9 10:07:17 2008
Subject: [cgiapp] cgiapp with Net::Server
In-Reply-To: <1205017488.7068.46.camel@zoe.savage.net.au>
References: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
	<1205017488.7068.46.camel@zoe.savage.net.au>
Message-ID: <d69cc4a60803090707l3ad58c65u6b5c007b724df6e1@mail.gmail.com>

On Sat, Mar 8, 2008 at 4:04 PM, Ron Savage <ron@savage.net.au> wrote:
> Hi Torsten

Ron, Torsten emailed it to me yesterday. What I found is that it
doesn't work with N::S's PreFork "personality." But, it works fine
with the "Fork" personality. So, it has something to do with how N::S
creates (and maintains) some children.

The next thing I found is that the environment contains the correct
runmode. But, the C::A instance thinks it's a different run mode. You
can add something to his webApp.pm to dump the environment and you'll
see it has "rm=1" even though the method for runmode 2 is being
executed.

I was going to dump the query object and then discovered, if I do "my
$q = $self->query()" anywhere in webApp.pm, the problem disappears.

So, it seems like cgi.pm is persisting. But, I don't understand how.
I'm to the end of my capability. If you can figure it out it would be
interesting to know what's going on.

Mark
From lecar_red at yahoo.com  Sun Mar  9 17:09:37 2008
From: lecar_red at yahoo.com (Lee Carmichael)
Date: Sun Mar  9 17:09:39 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
Message-ID: <780138.84731.qm@web31402.mail.mud.yahoo.com>

Hello Michael, 
 
>>  [me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]>  perl  Makefile.PL 
>>  This  module  can  optionally  use  Apache::Test  to  test  the  mod_perl  
>>  functionality. 
>>  Undefined  subroutine  &ExtUtils::MakeMaker::prompt  called  at  Makefile.PL  
>>  line  31,  <DATA>  line  547. 
 
> I'm  curious  about  this  one.  I'm  not  sure  which  version  of  ExtUtils::MakeMaker 
> added  prompt  (it's  in  at  least  6.31,  but  I  don't  know  about  6.30).  It  works  just 
> fine  for  me. 
 
This isn't a problem with ExtUtils::MakeMaker not having prompt in some old version, it is an issue with trying to use the 'prompt' sub before requiring the library. The require of it occurs only if you install module::build above, if you have it installed it makemaker won't get loaded.
 
<snippet> 
# see if they have Apache::Test, if not, ask if they want it 
my $build_pkg = 'Module::Build'; unless(eval "use Apache::Test 1.30; 1") {     
   print "This module can optionally use Apache::Test to test the mod_perl functionality.\n";     
   my $yn = ExtUtils::MakeMaker::prompt('  Install Apache::Test now from CPAN?', 'y');
</snippet>
  
> I  am  trying  to  be  smarter  than  the  average  Makefile.PL,  but  I  just  seem  to  be 
> getting  more  trouble  then  it's  work  at  this  point.  I'll  probably  just  go  back  to 
> being  dumb  and  not  run  the  Apache/mod_perl  tests  unless  the  person  already  have 
> Apache::Test  installed. 

I think its nice to try this. These problems aren't anything major.
 
>>  [me@unixbox1:~/perltemp/CGI-Application-Dispatch-2.12]>  perl  Build.PL 
>>  Can't  locate  object  method  "new"  via  package  "Module::Build"  (perhaps  you  
>>  forgot  to  load  "Module::Build"?)  at  Build.PL  line  2. 
 
> You  need  to  install  Module::Build  using  CPAN. 

I had Module::Build installed, the problem was w/out apache::testmb it didn't try to require or use it.


Here is the snippet from the Build.PL:


my $build_pkg = eval "require Apache::TestMB" ? 'Apache::TestMB' : 'Module::Build';
my $build = $build_pkg->new( ...


If you notice Module::Build is never loaded.

 >  Is  there  a  known  problem  with  CGI::Application::Dispatch?   How  have  others  
>  installed  this? 


I had these same issues but once I patched the Makefile.PL and Build.PL it worked just fine.


These are really small things and nothing to get angry about. Thanks for your work on C:A:Dispatch, it is a great tool. 


Take Care,


Lee

From ron at savage.net.au  Sun Mar  9 19:17:19 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Mar  9 19:15:02 2008
Subject: [cgiapp] cgiapp with Net::Server
In-Reply-To: <d69cc4a60803090707l3ad58c65u6b5c007b724df6e1@mail.gmail.com>
References: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
	<1205017488.7068.46.camel@zoe.savage.net.au>
	<d69cc4a60803090707l3ad58c65u6b5c007b724df6e1@mail.gmail.com>
Message-ID: <1205104639.7068.59.camel@zoe.savage.net.au>

Hi Mark

The sample code uses Net::Server::PreFork. I'm not sure, but if you have
multiple server processes waiting for connexions, it's possible the
first run mode is run inside one process, and the second run mode is run
inside a different process, right? That would explain how a run mode is
fixed inside a given process.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From azfuller at gmail.com  Sun Mar  9 19:49:17 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sun Mar  9 19:49:19 2008
Subject: [cgiapp] cgiapp with Net::Server
In-Reply-To: <1205104639.7068.59.camel@zoe.savage.net.au>
References: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
	<1205017488.7068.46.camel@zoe.savage.net.au>
	<d69cc4a60803090707l3ad58c65u6b5c007b724df6e1@mail.gmail.com>
	<1205104639.7068.59.camel@zoe.savage.net.au>
Message-ID: <d69cc4a60803091649n273e617bj6f2003ae8d62d6a8@mail.gmail.com>

On Sun, Mar 9, 2008 at 4:17 PM, Ron Savage <ron@savage.net.au> wrote:
>  The sample code uses Net::Server::PreFork. I'm not sure, but if you have
>  multiple server processes waiting for connexions, it's possible the
>  first run mode is run inside one process, and the second run mode is run
>  inside a different process, right? That would explain how a run mode is
>  fixed inside a given process.

I don't know. But, each process has the correct environment. For
example if you add "print $ENV{REQUEST_URI}" to Turston's WebApp.pm
(in each run-mode method), it will show that the URI has the correct
run mode. But, that's *not* the runmode C:A knows about.

It seems like CGI.pm is remaining persistent. But, I don't understand
why because the WebApp.pm is created "new" each time.

And, like I said, if you add "my $q = $self->query()" somewhere in
WebApp.pm the odd behavior stops. It also stops if I add a
"cgiapp_get_query" method to use CGI::Simple.

Turston's ok with using fork instead of PreFork. It's still puzzling
though. And beyond my capability to figure out.

Mark
From ceeshek at gmail.com  Sun Mar  9 20:36:19 2008
From: ceeshek at gmail.com (Cees Hek)
Date: Sun Mar  9 20:36:21 2008
Subject: [cgiapp] Test Failures with CGI::Application::Plugin::TT
In-Reply-To: <47CD6D2D.29220.12810A9@lackhoff.zbmed.uni-koeln.de>
References: <47CD6D2D.29220.12810A9@lackhoff.zbmed.uni-koeln.de>
Message-ID: <fd8e28ef0803091736o670c8278l404b31a072aca79f@mail.gmail.com>

Hi Michael,

I knew about these problems already because of the amazing CPAN
testers.  However, I was waiting for someone to pipe up that might
help me in solving the problems :)

The first two problems look to be cosmetic issues in Template Toolkit
(ie it is using the wrong path separator on windows).  My guess is
that this doesn't actually cause any problems, but we should be able
to fix the test suite to account for it.

Like you said, the third problem looks like it could be an issue
(although it is only an issue with the new precompile feature, so
upgrading on windows should still be safe if you avoid that new
feature).  I don't have a windows box to play with so there is not
much I can do to fix this.  I would appreciate if someone could take a
few minutes to do some debugging.  A patch would be greatly
appreciated, and/or SVN access to my CAP::TT repo can be organized for
anyone willing to put in a bit of time to fix this problem.

Cheers,

Cees


On Wed, Mar 5, 2008 at 1:39 AM, Michael Lackhoff
<lackhoff@zbmed.uni-koeln.de> wrote:
> Hello Cees,
>
>  thanks for the new versions of your plugins. Everything looks fine with
>  a tiny exception:
>
>  t/09_precompile_dir......1/6
>  #   Failed test 'file is cached'
>  #   at t/09_precompile_dir.t line 31.
>  #          got: 'C:\.cpan\build\CGI-Application-Plugin-TT-
>  1.04\t\include1\TestAppIncludePath/test_mode.tmpl'
>  #     expected: 'C:\.cpan\build\CGI-Application-Plugin-TT-
>  1.04\t\include1\TestAppIncludePath\test_mode.tmpl'
>
>  #   Failed test 'file is cached'
>  #   at t/09_precompile_dir.t line 31.
>  #          got: 'C:\.cpan\build\CGI-Application-Plugin-TT-
>  1.04\t\include1\TestAppIncludePath/test_mode.tmpl'
>  #     expected: 'C:\.cpan\build\CGI-Application-Plugin-TT-
>  1.04\t\include1\TestAppIncludePath\test_mode.tmpl'
>
>  #   Failed test 'file is cached'
>  #   at t/09_precompile_dir.t line 31.
>  #          got: undef
>  #     expected: 'C:\.cpan\build\CGI-Application-Plugin-TT-
>  1.04\t\include1\TestAppIncludePath\test_mode.tmpl'
>  # Looks like you failed 3 tests of 6.
>  t/09_precompile_dir...... Dubious, test returned 3 (wstat 768, 0x300)
>   Failed 3/6 subtests
>
>  It looks as if the first two are harmless (just one slash/backslash
>  mixed up) but the third error looks like something is really going
>  wrong.
>  As you can guess from the "C:\..." everything is under Windows 2000,
>  Perl is a self-compiled 5.8.8 with VC6 from the official sources (not
>  Activestate).
>
>  Any ideas?
>  -Michael
>
>
>  #####  CGI::Application community mailing list  ################
>  ##                                                            ##
>  ##  To unsubscribe, or change your message delivery options,  ##
>  ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
>  ##                                                            ##
>  ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
>  ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
>  ##                                                            ##
>  ################################################################
>
>
From azfuller at gmail.com  Sun Mar  9 20:50:31 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sun Mar  9 20:50:34 2008
Subject: [cgiapp] cgiapp with Net::Server
In-Reply-To: <d69cc4a60803091649n273e617bj6f2003ae8d62d6a8@mail.gmail.com>
References: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
	<1205017488.7068.46.camel@zoe.savage.net.au>
	<d69cc4a60803090707l3ad58c65u6b5c007b724df6e1@mail.gmail.com>
	<1205104639.7068.59.camel@zoe.savage.net.au>
	<d69cc4a60803091649n273e617bj6f2003ae8d62d6a8@mail.gmail.com>
Message-ID: <d69cc4a60803091750pb07d862j70b5b436742340d0@mail.gmail.com>

Browsing the source for CGI.pm I noticed it calls
"initialize_globals()" when the class is loaded, but not when
instances are created. But, it does call it for each instance if the
mod_perl environment variable is set. (But, that does other things you
wouldn't want to do if you're not really using mod_perl). I also
noticed that it detects ActiveState's "PerlEx" (persistent Perl
utility) and calls "_reset_globals" which calls "initialize_globals".

I added a teardown method to Torsten's WebApp.pm and called
"$self->query()->initialize_globals()". The problem disappeared. (I
used teardown because that was the only place I could think to do it.
I guess a cgiapp_get_query would be more appropriate. Do the "new" and
then initialize_globals.).

So, it's definitely an issue with CGI.pm.  Apparently the params are
globals (class data). And, it doesn't have a catch-all "persistence"
flag. It has a flag for mod_perl. And, detects PerlEx. But, if you use
something else (like Net::Server's prefork) you're screwed.

CGI::Simple doesn't have this problem. The params aren't class data.
And, it calls initialize_globals with each instance (without going
through a bunch of questions about mod_perl or perlex). Reminds me why
I like CGI::Simple.

Mark
From ron at savage.net.au  Sun Mar  9 23:15:35 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Mar  9 23:13:40 2008
Subject: [cgiapp] cgiapp with Net::Server
In-Reply-To: <d69cc4a60803091750pb07d862j70b5b436742340d0@mail.gmail.com>
References: <20080308110526.27f75272@apfeltasche.neo2k.homeip.net>
	<1205017488.7068.46.camel@zoe.savage.net.au>
	<d69cc4a60803090707l3ad58c65u6b5c007b724df6e1@mail.gmail.com>
	<1205104639.7068.59.camel@zoe.savage.net.au>
	<d69cc4a60803091649n273e617bj6f2003ae8d62d6a8@mail.gmail.com>
	<d69cc4a60803091750pb07d862j70b5b436742340d0@mail.gmail.com>
Message-ID: <1205118935.7068.61.camel@zoe.savage.net.au>

HI Mark

On Sun, 2008-03-09 at 17:50 -0700, Mark Fuller wrote:
> Browsing the source for CGI.pm I noticed it calls
> "initialize_globals()" when the class is loaded, but not when
> instances are created. But, it does call it for each instance if the
> mod_perl environment variable is set. (But, that does other things you
> wouldn't want to do if you're not really using mod_perl). I also
> noticed that it detects ActiveState's "PerlEx" (persistent Perl
> utility) and calls "_reset_globals" which calls "initialize_globals".
> 
> I added a teardown method to Torsten's WebApp.pm and called
> "$self->query()->initialize_globals()". The problem disappeared. (I
> used teardown because that was the only place I could think to do it.
> I guess a cgiapp_get_query would be more appropriate. Do the "new" and
> then initialize_globals.).

Good bit of detective work. Well done.

> So, it's definitely an issue with CGI.pm.  Apparently the params are
> globals (class data). And, it doesn't have a catch-all "persistence"
> flag. It has a flag for mod_perl. And, detects PerlEx. But, if you use
> something else (like Net::Server's prefork) you're screwed.
> 
> CGI::Simple doesn't have this problem. The params aren't class data.
> And, it calls initialize_globals with each instance (without going
> through a bunch of questions about mod_perl or perlex). Reminds me why
> I like CGI::Simple.

Yep - don't we all...
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ron at savage.net.au  Mon Mar 10 02:02:56 2008
From: ron at savage.net.au (Ron Savage)
Date: Mon Mar 10 02:00:24 2008
Subject: [cgiapp] Test Failures with CGI::Application::Plugin::TT
In-Reply-To: <fd8e28ef0803091736o670c8278l404b31a072aca79f@mail.gmail.com>
References: <47CD6D2D.29220.12810A9@lackhoff.zbmed.uni-koeln.de>
	<fd8e28ef0803091736o670c8278l404b31a072aca79f@mail.gmail.com>
Message-ID: <1205128976.7068.70.camel@zoe.savage.net.au>

Hi Cees

On Mon, 2008-03-10 at 11:36 +1100, Cees Hek wrote:
> Hi Michael,
> 
> I knew about these problems already because of the amazing CPAN
> testers.  However, I was waiting for someone to pipe up that might
> help me in solving the problems :)
> 
> The first two problems look to be cosmetic issues in Template Toolkit
> (ie it is using the wrong path separator on windows).  My guess is
> that this doesn't actually cause any problems, but we should be able
> to fix the test suite to account for it.

It's a bug in Template.

See line 213 of Template::Provider.pm, where a hard-coded '/' explains
why that happens. I did not log a report on RT, but you can after
cross-checking my claim :-)).

> Like you said, the third problem looks like it could be an issue
> (although it is only an issue with the new precompile feature, so
> upgrading on windows should still be safe if you avoid that new
> feature).  I don't have a windows box to play with so there is not
> much I can do to fix this.  I would appreciate if someone could take a
> few minutes to do some debugging.  A patch would be greatly
> appreciated, and/or SVN access to my CAP::TT repo can be organized for
> anyone willing to put in a bit of time to fix this problem.

If you put these lines in 09_precompile_dir.t just after line 33 you'll
see there is no key 'HEAD' in the hash.
print "SERVICE:        $$tt{SERVICE}. \n";
print "CONTEXT:        $$tt{SERVICE}{CONTEXT}. \n";
print "LOAD_TEMPLATES: $$tt{SERVICE}{CONTEXT}{LOAD_TEMPLATES}. \n";
print "[0]:            $$tt{SERVICE}{CONTEXT}{LOAD_TEMPLATES}[0]. \n";
print "HEAD:           $$tt{SERVICE}{CONTEXT}{LOAD_TEMPLATES}[0]{HEAD}.
\n";
print "KEYS: \n",
map{"$_ => $$tt{SERVICE}{CONTEXT}{LOAD_TEMPLATES}[0]{$_}. \n"} sort keys
%{$$tt{SERVICE}{CONTEXT}{LOAD_TEMPLATES}[0]};

Output:
C:\perl.modules\CGI-Application-Plugin-TT-1.04>perl -Ilib t
\09_precompile_dir.t
1..6
tt_dir: t\include1\TestAppIncludePath.
file:   C:\perl.modules\CGI-Application-Plugin-TT-1.04\t\include1
\TestAppIncludePath\test_mode.tmpl.
SERVICE:        Template::Service=HASH(0xc4609c).
CONTEXT:        Template::Context=HASH(0xc71344).
LOAD_TEMPLATES: ARRAY(0xc716e4).
[0]:            Template::Provider=HASH(0xc715a4).
HEAD:           .
KEYS:
 => .
0 => .
ABSOLUTE => 1.
COMPILE_DIR => .
COMPILE_EXT => .
DEBUG => 0.
DEFAULT => .
DELIMITER => :(?!\/).
DOCUMENT => Template::Document.
ENCODING => .
INCLUDE_PATH => ARRAY(0xc71544).
LOOKUP => HASH(0xc71534).
NOTFOUND => HASH(0xc71564).
PARAMS => HASH(0xc45cbc).
PARSER => .
RELATIVE => 0.
SIZE => .
SLOTS => 0.
STAT_TTL => 1.
TOLERANT => 0.
UNICODE => 1.
_ERROR => .
not ok 1 - file is cached
#   Failed test 'file is cached'
#   at t\09_precompile_dir.t line 41.
#          got: undef
#     expected: 'C:\perl.modules\CGI-Application-Plugin-TT-1.04\t
\include1\TestAppIncludePath\test_mode.tmpl'
# Looks like you planned 6 tests but only ran 1.
# Looks like you failed 1 test of 1 run.

HTH.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From ron at savage.net.au  Mon Mar 10 02:42:48 2008
From: ron at savage.net.au (Ron Savage)
Date: Mon Mar 10 02:40:19 2008
Subject: [cgiapp] Test Failures with CGI::Application::Plugin::TT
In-Reply-To: <1205128976.7068.70.camel@zoe.savage.net.au>
References: <47CD6D2D.29220.12810A9@lackhoff.zbmed.uni-koeln.de>
	<fd8e28ef0803091736o670c8278l404b31a072aca79f@mail.gmail.com>
	<1205128976.7068.70.camel@zoe.savage.net.au>
Message-ID: <1205131368.7068.73.camel@zoe.savage.net.au>

Hi Ron

> It's a bug in Template.
> 
> See line 213 of Template::Provider.pm, where a hard-coded '/' explains
> why that happens. I did not log a report on RT, but you can after
> cross-checking my claim :-)).

Oops. Patching Template::Provider by replacing '/' with '\\' did not fix
those 2 errors. Oh, well. I still assume the Template code has a bug in
it at that point.

-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From perl.cgiapp at rjbs.manxome.org  Mon Mar 10 06:56:38 2008
From: perl.cgiapp at rjbs.manxome.org (Ricardo SIGNES)
Date: Mon Mar 10 06:56:50 2008
Subject: [cgiapp] enciphered-cookie-only sessions
Message-ID: <20080310105638.GA7656@knight.local>


Leon Brocard recently uploaded this:

  http://search.cpan.org/~lbrocard/Catalyst-Plugin-CookiedSession-0.32/lib/Catalyst/Plugin/CookiedSession.pm

It's a Catalyst plugin that stores your whole session in the cookie.  It's
stored as a base64-encoded, Rijndael-enciphered, JSON-encoded string.  This
seemed like a swell idea for me, since:

  a. I'm tired of session files cluttering things up.
  b. I don't feel like creating a session db.
  c. My session contents are tiny.

I threw together a quick implementation last night, just for Rubric, and I've
already replaced my use of CAP::Session with it.  I'll refactor it for use as a
real plugin later this week, probably.

  http://git.codesimply.com/?p=Rubric;a=blob;f=lib/Rubric/WebApp/Session.pm;h=3c5f79623f02268a0512487d62e976c7fc0b47aa;hb=HEAD

-- 
rjbs
From azfuller at gmail.com  Mon Mar 10 09:06:30 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Mon Mar 10 09:06:33 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <20080310105638.GA7656@knight.local>
References: <20080310105638.GA7656@knight.local>
Message-ID: <d69cc4a60803100606s46d5cb20l38a48f4963373bbe@mail.gmail.com>

On Mon, Mar 10, 2008 at 3:56 AM, Ricardo SIGNES
<perl.cgiapp@rjbs.manxome.org> wrote:
> stores your whole session in the cookie.  It's  stored as a base64-encoded,
> Rijndael-enciphered, JSON-encoded string.  This  seemed like a swell idea for me,

I hear a lot about brute-force attacks on encryption. Also, that what
seemed like a terrific amount of brute force 5-10 years ago isn't
today. Is that a concern (if someone steals cookies)?

Mark
From jason at journalistic.com  Mon Mar 10 09:14:28 2008
From: jason at journalistic.com (Jason Purdy)
Date: Mon Mar 10 09:14:34 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <20080310105638.GA7656@knight.local>
References: <20080310105638.GA7656@knight.local>
Message-ID: <47D53434.6070206@journalistic.com>

This probably goes without saying, but I would add that this approach 
isn't for every application.  For example, we have an e-commerce 
application that has our user leaving our site to complete a credit card 
transaction and then comes back to our site to complete the order with 
the session id.  Very rarely, a disconnect happens where the user has 
paid at the credit card site and their cookie was deleted on the client 
side.  When that does happen, I'm able to manually reconcile the credit 
card transaction against the session information we have on our server.

If we used this technique and that disconnect happened, I would have to 
void the transaction because I have lost the order information.

- Jason

Ricardo SIGNES wrote:
> Leon Brocard recently uploaded this:
> 
>   http://search.cpan.org/~lbrocard/Catalyst-Plugin-CookiedSession-0.32/lib/Catalyst/Plugin/CookiedSession.pm
> 
> It's a Catalyst plugin that stores your whole session in the cookie.  It's
> stored as a base64-encoded, Rijndael-enciphered, JSON-encoded string.  This
> seemed like a swell idea for me, since:
> 
>   a. I'm tired of session files cluttering things up.
>   b. I don't feel like creating a session db.
>   c. My session contents are tiny.
> 
> I threw together a quick implementation last night, just for Rubric, and I've
> already replaced my use of CAP::Session with it.  I'll refactor it for use as a
> real plugin later this week, probably.
> 
>   http://git.codesimply.com/?p=Rubric;a=blob;f=lib/Rubric/WebApp/Session.pm;h=3c5f79623f02268a0512487d62e976c7fc0b47aa;hb=HEAD
> 
From mpeters at plusthree.com  Mon Mar 10 09:15:26 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Mon Mar 10 09:18:12 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <20080310105638.GA7656@knight.local>
References: <20080310105638.GA7656@knight.local>
Message-ID: <47D5346E.7050504@plusthree.com>

Ricardo SIGNES wrote:

> It's a Catalyst plugin that stores your whole session in the cookie.  It's
> stored as a base64-encoded, Rijndael-enciphered, JSON-encoded string. 

Krang does this as well and I've used it on lots of other projects too. But, I
think that's a little overkill. I just use a URL encoded JSON cookie. I don't
put anything sensitive in there. I usually use this in conjunction with a normal
session cookie. So the sensitive stuff goes into the server side session and the
non-sensitive stuff in the client side session.

The nice thing about putting things into the cookie in an easy to read JSON
format is that my client side AJAX/Javascript code can use it too. For instance,
Krang has a user preference to determine how long you want the messages that
slide-in to remain visible. With this stored in this JSON cookie we can access
that from the Javascript, since that's what creates the slide-in messages in the
first place.

> This
> seemed like a swell idea for me, since:
> 
>   a. I'm tired of session files cluttering things up.
>   b. I don't feel like creating a session db.
>   c. My session contents are tiny.

The reason I use 2 session cookies (one just the key to the server side session
and the other a JSON cookie) is mainly because of (c). Cookie size is limited
and I can't guarantee that some people's sessions won't get really big.

> I threw together a quick implementation last night, just for Rubric, and I've
> already replaced my use of CAP::Session with it.  I'll refactor it for use as a
> real plugin later this week, probably.
> 
>   http://git.codesimply.com/?p=Rubric;a=blob;f=lib/Rubric/WebApp/Session.pm;h=3c5f79623f02268a0512487d62e976c7fc0b47aa;hb=HEAD

I've been meaning to add something like this to CGI::Application::Plugin::JSON,
but haven't gotten around to it yet.

-- 
Michael Peters
Plus Three, LP

From azfuller at gmail.com  Mon Mar 10 09:27:47 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Mon Mar 10 09:27:49 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <47D5346E.7050504@plusthree.com>
References: <20080310105638.GA7656@knight.local>
	<47D5346E.7050504@plusthree.com>
Message-ID: <d69cc4a60803100627i14db5930gf6d0eafd3454d71e@mail.gmail.com>

On Mon, Mar 10, 2008 at 6:15 AM, Michael Peters <mpeters@plusthree.com> wrote:
>
> I just use a URL encoded JSON cookie. I don't  put anything sensitive in there.

Is there a risk that this contributes to the bad reputation of
cookies? One person puts stuff in a cookie and obfuscates it
(presumably for a reason). Another encrypts it (presumably for a
reason). There's no transparency for the user who isn't even asked if
they accept this.

To me, it sounds like the kind of thing that makes people disable
cookies entirely (or, trust them too much and, before too long
someone's definition of what's "not sensitive" and "satisfactory
obfuscation" is incorrect). It seems like just storing a sessionID
avoids all that. Is making the programming less complex worth falling
into that category of cookie suspicion?

Mark
From Todd_Ross at mgic.com  Mon Mar 10 09:56:31 2008
From: Todd_Ross at mgic.com (Todd Ross)
Date: Mon Mar 10 09:56:56 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
In-Reply-To: <47D2DA62.3070504@plusthree.com>
Message-ID: <OF80390F10.C36C6C10-ON86257408.004AF5FE-86257408.004C962D@mgic.com>

Michael,

> Ok, not instead of trying to use the toolchain to install Module::
> Build and then
> Apache::Test (if you answered yes at the prompt) I'm just going to be 
really
> dumb. If you have Apache::Test on your machine I will use it and run the
> mod_perl tests as well as the CGI ones. Else I won't. And since 
apparently not
> everyone has upgraded their toolchain to include Module::Build I'll 
include a
> normal Makefile.PL in the distribution.

I have Module::Build installed.  I've used it to install many other 
modules.  As Lee pointed out, I believe that both problems I encountered 
are in CGI::Application::Dispatch's Build.PL and Makefile.PL scripts.  I 
understand that it's trying to do some conditional checks and/or makes 
some assumptions during the install, but when it doesn't work then part of 
the audience ends up getting inadvertantly locked out.  If I wasn't 
already subscribed to this list, I wouldn't have posted the question and 
wouldn't have been pointed to the bug entry supplied by Lee.

> I do have to say though that it really bothers me to have to make my 
modules
> work for people who don't want to bother with upgrading their toolchain 
:)

Is it unreasonable to believe that CPAN modules should be compatible with 
the toolchain distributed with recent versions of Perl?  I'm on Perl 
v5.8.8 and ExtUtils::MakeMaker is shipped as v6.30.  Module::Build isn't 
included, so that one I installed myself.  But, as Lee pointed out, the 
version of ExtUtils::MakeMaker or Build::Install isn't the problem here.

Thanks for the pointers, Lee.  I'm going to give the new 
CGI::Application::Dispatch that Michael uploaded to CPAN a shot first 
though.

Todd
From cromedome at gmail.com  Mon Mar 10 10:46:03 2008
From: cromedome at gmail.com (Jason A. Crome)
Date: Mon Mar 10 10:46:09 2008
Subject: [cgiapp] CGI::Application in a coding contest
Message-ID: <6C46A3DD-5BD5-468C-AA09-19B8E6DB6F07@gmail.com>

I received this last week from Josh McAdams.  Sorry for not passing it  
along sooner, but I was out sick most of last week.  I don't have time  
to do this, but if anyone does and is interested, please get back to  
me ASAP so I can let him know.

Thanks!
Jason

---

Hi Jason, I hope things are going well.  I was contacting you because
I've been working with the organizers of Flourish
(http://www.flourishconf.com) to get Perl added to a web framework
showdown that they are going to have at the conference.  I'm trying to
get as many Perl-based frameworks as I can to represent.  Do you know
of anyone (possibly you and one other) that could represent
CGI::Application?  The organizers mentioned that they might be able to
pay for travel, so you can suggest beyond the midwest if need be.

Thanks,
Josh
From rdice at pobox.com  Mon Mar 10 10:49:31 2008
From: rdice at pobox.com (Richard Dice)
Date: Mon Mar 10 10:49:38 2008
Subject: [cgiapp] CGI::Application in a coding contest
In-Reply-To: <6C46A3DD-5BD5-468C-AA09-19B8E6DB6F07@gmail.com>
References: <6C46A3DD-5BD5-468C-AA09-19B8E6DB6F07@gmail.com>
Message-ID: <5bef4baf0803100749j460687bbt72a7bbcd3f9cb35@mail.gmail.com>

Cees, want a trip back to N. America? :-)

Cheers,
 - Richard

On Mon, Mar 10, 2008 at 10:46 AM, Jason A. Crome <cromedome@gmail.com>
wrote:

> I received this last week from Josh McAdams.  Sorry for not passing it
> along sooner, but I was out sick most of last week.  I don't have time
> to do this, but if anyone does and is interested, please get back to
> me ASAP so I can let him know.
>
> Thanks!
> Jason
>
> ---
>
> Hi Jason, I hope things are going well.  I was contacting you because
> I've been working with the organizers of Flourish
> (http://www.flourishconf.com) to get Perl added to a web framework
> showdown that they are going to have at the conference.  I'm trying to
> get as many Perl-based frameworks as I can to represent.  Do you know
> of anyone (possibly you and one other) that could represent
> CGI::Application?  The organizers mentioned that they might be able to
> pay for travel, so you can suggest beyond the midwest if need be.
>
> Thanks,
> Josh
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>
From mpeters at plusthree.com  Mon Mar 10 11:03:23 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Mon Mar 10 11:06:10 2008
Subject: [cgiapp] CGI::Application in a coding contest
In-Reply-To: <6C46A3DD-5BD5-468C-AA09-19B8E6DB6F07@gmail.com>
References: <6C46A3DD-5BD5-468C-AA09-19B8E6DB6F07@gmail.com>
Message-ID: <47D54DBB.5050704@plusthree.com>

Jason A. Crome wrote:
> I received this last week from Josh McAdams.  Sorry for not passing it
> along sooner, but I was out sick most of last week.  I don't have time
> to do this, but if anyone does and is interested, please get back to me
> ASAP so I can let him know.

This would be fun, but alas, I'm in Olso Norway for the Perl QA Workshop that
weekend.

-- 
Michael Peters
Plus Three, LP

From perrin at elem.com  Mon Mar 10 11:28:09 2008
From: perrin at elem.com (Perrin Harkins)
Date: Mon Mar 10 11:28:40 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <d69cc4a60803100627i14db5930gf6d0eafd3454d71e@mail.gmail.com>
References: <20080310105638.GA7656@knight.local>
	<47D5346E.7050504@plusthree.com>
	<d69cc4a60803100627i14db5930gf6d0eafd3454d71e@mail.gmail.com>
Message-ID: <66887a3d0803100828x6174a784ye39076a68f581a5e@mail.gmail.com>

On Mon, Mar 10, 2008 at 9:27 AM, Mark Fuller <azfuller@gmail.com> wrote:
>  To me, it sounds like the kind of thing that makes people disable
>  cookies entirely

Have you tried browsing the web without cookies recently?  It doesn't
work at all on a large number of popular sites.  For better or worse,
cookies are a part of the deal now.

- Perrin
From azfuller at gmail.com  Mon Mar 10 11:43:04 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Mon Mar 10 11:43:08 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <66887a3d0803100828x6174a784ye39076a68f581a5e@mail.gmail.com>
References: <20080310105638.GA7656@knight.local>
	<47D5346E.7050504@plusthree.com>
	<d69cc4a60803100627i14db5930gf6d0eafd3454d71e@mail.gmail.com>
	<66887a3d0803100828x6174a784ye39076a68f581a5e@mail.gmail.com>
Message-ID: <d69cc4a60803100843u6362c629ib7b1d4d30d9e228a@mail.gmail.com>

On Mon, Mar 10, 2008 at 8:28 AM, Perrin Harkins <perrin@elem.com> wrote:
>  Have you tried browsing the web without cookies recently?  It doesn't
>  work at all on a large number of popular sites.  For better or worse,
>  cookies are a part of the deal now.

But that doesn't mean anything belongs in a cookie. It seems to me if
it can't be clear text it shouldn't be in a cookie. At least if it's
clear text I have the opportunity to see what's going on and make a
choice about whether to accept cookies from a site.

I'd go further and say nothing but a session key should go in a
cookie. Once it turns into additional elements, opinions differ about
what's sensitive or not (userid?, first and last names?, mailing
address? date of birth? credit card number?). If it's just a session
key there's not a lot to think about. If it contains more than that
there's always the risk that the cookie setter's ideas violate my
sense of privacy or security. If it's encrypted, who knows what's
going on. The fact that it warrants encryption would give me concern.

Mark
From azfuller at gmail.com  Mon Mar 10 11:46:27 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Mon Mar 10 11:46:30 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <66887a3d0803100828x6174a784ye39076a68f581a5e@mail.gmail.com>
References: <20080310105638.GA7656@knight.local>
	<47D5346E.7050504@plusthree.com>
	<d69cc4a60803100627i14db5930gf6d0eafd3454d71e@mail.gmail.com>
	<66887a3d0803100828x6174a784ye39076a68f581a5e@mail.gmail.com>
Message-ID: <d69cc4a60803100846o33ac3b60oe3ac56184915a417@mail.gmail.com>

On Mon, Mar 10, 2008 at 8:28 AM, Perrin Harkins <perrin@elem.com> wrote:
>  Have you tried browsing the web without cookies recently?  It doesn't
>  work at all on a large number of popular sites.  For better or worse,
>  cookies are a part of the deal now.

BTW: I didn't understand the part in the Catalyst documentation saying
the benefit of sending the session in the cookie is that you don't
have to access the disk. I assume that's supposed to be a performance
benefit. But, after two encodings and an encryption, and two decodings
and a decryption? I don't see how that could be much of a performance
boost.

Mark
From perl.cgiapp at rjbs.manxome.org  Mon Mar 10 12:54:03 2008
From: perl.cgiapp at rjbs.manxome.org (Ricardo SIGNES)
Date: Mon Mar 10 12:54:13 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <d69cc4a60803100606s46d5cb20l38a48f4963373bbe@mail.gmail.com>
References: <20080310105638.GA7656@knight.local>
	<d69cc4a60803100606s46d5cb20l38a48f4963373bbe@mail.gmail.com>
Message-ID: <20080310165403.GA9286@knight.local>

* Mark Fuller <azfuller@gmail.com> [2008-03-10T09:06:30]
> On Mon, Mar 10, 2008 at 3:56 AM, Ricardo SIGNES
> <perl.cgiapp@rjbs.manxome.org> wrote:
> > stores your whole session in the cookie.  It's  stored as a base64-encoded,
> > Rijndael-enciphered, JSON-encoded string.  This  seemed like a swell idea
> > for me,
> 
> I hear a lot about brute-force attacks on encryption. Also, that what
> seemed like a terrific amount of brute force 5-10 years ago isn't
> today. Is that a concern (if someone steals cookies)?

I think the amount of brute force required would still be pretty darn brutal.
I wouldn't use this for anything like banking or credit cards, but I feel
pretty okay about it for things like a Rubric login.

Probably what I'll do in the (near) future is have an n-day log of secrets,
generated daily.  The cookie will then be like

  { generated: yyyymmdd, cookie: ciphertext }

You'll have to crack the secret within n days, which makes it even more
tedious.

Anyway, like I said, and like others say, this isn't for everyone or
everything.

-- 
rjbs
From perl.cgiapp at rjbs.manxome.org  Mon Mar 10 12:59:57 2008
From: perl.cgiapp at rjbs.manxome.org (Ricardo SIGNES)
Date: Mon Mar 10 13:00:07 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <47D5346E.7050504@plusthree.com>
References: <20080310105638.GA7656@knight.local>
	<47D5346E.7050504@plusthree.com>
Message-ID: <20080310165957.GB9286@knight.local>

* Michael Peters <mpeters@plusthree.com> [2008-03-10T09:15:26]
> Ricardo SIGNES wrote:
> > It's a Catalyst plugin that stores your whole session in the cookie.  It's
> > stored as a base64-encoded, Rijndael-enciphered, JSON-encoded string. 
> 
> Krang does this as well and I've used it on lots of other projects too. But,
> I think that's a little overkill. I just use a URL encoded JSON cookie. I
> don't put anything sensitive in there. I usually use this in conjunction with
> a normal session cookie. So the sensitive stuff goes into the server side
> session and the non-sensitive stuff in the client side session.

Right... the encryption ceases to be overkill when you eliminate the
server-side cookie and don't want someone to be able to change his username!

> The nice thing about putting things into the cookie in an easy to read JSON
> format is that my client side AJAX/Javascript code can use it too. For
> instance, Krang has a user preference to determine how long you want the
> messages that slide-in to remain visible. With this stored in this JSON
> cookie we can access that from the Javascript, since that's what creates the
> slide-in messages in the first place.

Yeah, that's an interesting point.  I should extend my session definition to
have private and public data!

> The reason I use 2 session cookies (one just the key to the server side
> session and the other a JSON cookie) is mainly because of (c). Cookie size is
> limited and I can't guarantee that some people's sessions won't get really
> big.

Yeah.  Again, in this specific application, I know all the data that might go
into the session, and they are all small.

-- 
rjbs
From perl.cgiapp at rjbs.manxome.org  Mon Mar 10 13:05:58 2008
From: perl.cgiapp at rjbs.manxome.org (Ricardo SIGNES)
Date: Mon Mar 10 13:06:07 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <d69cc4a60803100627i14db5930gf6d0eafd3454d71e@mail.gmail.com>
References: <20080310105638.GA7656@knight.local>
	<47D5346E.7050504@plusthree.com>
	<d69cc4a60803100627i14db5930gf6d0eafd3454d71e@mail.gmail.com>
Message-ID: <20080310170558.GC9286@knight.local>

* Mark Fuller <azfuller@gmail.com> [2008-03-10T09:27:47]
> On Mon, Mar 10, 2008 at 6:15 AM, Michael Peters <mpeters@plusthree.com> wrote:
> >
> > I just use a URL encoded JSON cookie. I don't  put anything sensitive in
> > there.
> 
> Is there a risk that this contributes to the bad reputation of
> cookies? One person puts stuff in a cookie and obfuscates it
> (presumably for a reason). Another encrypts it (presumably for a
> reason). There's no transparency for the user who isn't even asked if
> they accept this.

Who obfuscated?  URI-encoding is just useful to make it 7-bit safe.  (I think!)
It's barely obfuscatory, too, if you know the few common things that will
appear.

I don't know that cookies have a bad reputation at all!  They're just
accessible to the user to view and edit, and they have a small maximum size.
Having a cookie containing "authenicated_user_name=rjbs" in the clear would be
stupid.  Trying to store a complete serialized set of preferences for a complex
application would also be stupid.

> To me, it sounds like the kind of thing that makes people disable cookies
> entirely (or, trust them too much and, before too long someone's definition
> of what's "not sensitive" and "satisfactory obfuscation" is incorrect). It
> seems like just storing a sessionID avoids all that. Is making the
> programming less complex worth falling into that category of cookie
> suspicion?

What's the kind of thing?  Huh?  I have no idea what you're driving at.

-- 
rjbs
From jspooner at liaison-intl.com  Mon Mar 10 13:56:38 2008
From: jspooner at liaison-intl.com (John Spooner)
Date: Mon Mar 10 13:56:40 2008
Subject: [cgiapp] Re: ValidateRM and dynamic content
Message-ID: <788CE35B4DF22443A7AA542796706AB501693A96@liex2.liaison-intl.com>

Sorry for the late response.  I was up against a deadline and had to
switch tactics, but wanted to post a follow up for at least archive
purposes.

The project ultimately produced surveys each with content that could be
classified into different form types (checkbox, radio, text, etc) and
some more complex forms (ex. Some checkbox and radio sections require
accompanying text (check "0ther" or "Please describe...")).  In any
event all questions belong to one variation of a form element.  I
created one template that contained all of the standard form info
(headers/footers, etc) and a loop that examines each question on that
template (question info is stored in a database) and displays the proper
form element.  Everything worked great until validation.  The problem
seems to lie in the fact that the name of the form element was
dynamically named.

Example:
	<input type="text" name="<TMPL_VAR foo>" maxlength....>

This works great for the original display of the template, but if errors
are detected there doesn't seem to be a way (that I can think of at
least) to template the error message.  My error messages have the prefix
'err' so to template error message I am left with:

<TMPL_IF err_<TMPL_VAR foo>>
	err_<TMPL_VAR foo>
</TMPL_IF>

The TMPL_IF line is not legal H::T syntax, so I tried the line without
TMPL_IF statements.  No matter what I did the error message would not
display.

I ended up creating one template for each survey section each with the
questions for each section explicitly defined (mostly static) in order
to get the project out the door.  I'd like to revisit the idea of one
dynamic template for this application because it would make annual
maintenance simple and adding new surveys trivial.

After I asked the list I did try creating a bit of HTML::Template code
separate from the dynamic template and then tried to include it back in.
The closest I came to making it work is error sections were created and
physically included in the template so that the TMPL_IF error code
posted above would be part of the page source of the HTML page.


-----Original Message-----
From: cgiapp-bounces@lists.erlbaum.net
[mailto:cgiapp-bounces@lists.erlbaum.net] On Behalf Of Mark Stosberg
Sent: Saturday, March 08, 2008 4:32 PM
To: cgiapp@lists.erlbaum.net
Subject: [cgiapp] Re: ValidateRM and dynamic content

>
> I am using HTML::Template and CGI::Application::Plugin::ValidateRM.
> Page content is generated dynamically which works fine until a
> validation error occurs.  Unfortunately <err_<TMPL_VAR field_name>> is
> not valid H::T.

Could you provide a more complete example? I have been using ValidateRM
and H::T with complex websites for years and haven't gotten stuck here.
I suspect there's another way to accomplish your goal while still using
sing these tools.

     Mark

-- 
http://mark.stosberg.com/



#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################


From lackhoff at zbmed.uni-koeln.de  Tue Mar 11 04:32:38 2008
From: lackhoff at zbmed.uni-koeln.de (Michael Lackhoff)
Date: Tue Mar 11 04:36:47 2008
Subject: [cgiapp] Test Failures with CGI::Application::Plugin::TT
In-Reply-To: <fd8e28ef0803091736o670c8278l404b31a072aca79f@mail.gmail.com>
References: <47CD6D2D.29220.12810A9@lackhoff.zbmed.uni-koeln.de>
Message-ID: <47D651B6.14398.23E4D35B@lackhoff.zbmed.uni-koeln.de>

Hi Cees,

> feature).  I don't have a windows box to play with so there is not
> much I can do to fix this.  I would appreciate if someone could take a
> few minutes to do some debugging.  A patch would be greatly
> appreciated, and/or SVN access to my CAP::TT repo can be organized for
> anyone willing to put in a bit of time to fix this problem.

I am willing to do whatever debugging seems helpful. Besides what Ron 
already tried, do you have any idea where I could look?

I won't be able to get at it before the weekend but I will definitely 
do what I can to fix this.
CAP, TT and CAP::TT with them are the heart of most of my applications 
so I am very interested to get the current version without a "force 
install".

-Michael

From mpeters at plusthree.com  Tue Mar 11 09:33:56 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Tue Mar 11 09:36:44 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <20080310165957.GB9286@knight.local>
References: <20080310105638.GA7656@knight.local>	<47D5346E.7050504@plusthree.com>
	<20080310165957.GB9286@knight.local>
Message-ID: <47D68A44.70706@plusthree.com>

Ricardo SIGNES wrote:

> Right... the encryption ceases to be overkill when you eliminate the
> server-side cookie and don't want someone to be able to change his username!

You could get both benefits (JS usable structure and tamper proof data) by
adding a hash key to the JSON structure. Then double check the server side data
with the hash key to make sure it wasn't tampered with.

> Yeah, that's an interesting point.  I should extend my session definition to
> have private and public data!

If you could wrap that all up into a plugin, or add it to C::A::P::Session that
would be pretty useful.

-- 
Michael Peters
Plus Three, LP

From perrin at elem.com  Tue Mar 11 09:59:46 2008
From: perrin at elem.com (Perrin Harkins)
Date: Tue Mar 11 09:59:48 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <d69cc4a60803100843u6362c629ib7b1d4d30d9e228a@mail.gmail.com>
References: <20080310105638.GA7656@knight.local>
	<47D5346E.7050504@plusthree.com>
	<d69cc4a60803100627i14db5930gf6d0eafd3454d71e@mail.gmail.com>
	<66887a3d0803100828x6174a784ye39076a68f581a5e@mail.gmail.com>
	<d69cc4a60803100843u6362c629ib7b1d4d30d9e228a@mail.gmail.com>
Message-ID: <66887a3d0803110659u3e8c15e1n8d83a8517c44655e@mail.gmail.com>

On Mon, Mar 10, 2008 at 11:43 AM, Mark Fuller <azfuller@gmail.com> wrote:
>  But that doesn't mean anything belongs in a cookie. It seems to me if
>  it can't be clear text it shouldn't be in a cookie. At least if it's
>  clear text I have the opportunity to see what's going on and make a
>  choice about whether to accept cookies from a site.

Again, have you tried turning on the "ask me" option for cookies
lately?  You'll find that many pages give you a dozen or so cookies
from various ad banners and the like.

Hardly anyone looks at cookies, and those who do will probably be
happier if they don't look like readable text.

>  I'd go further and say nothing but a session key should go in a
>  cookie. Once it turns into additional elements, opinions differ about
>  what's sensitive or not (userid?, first and last names?, mailing
>  address? date of birth? credit card number?).

Information that isn't sensitive can be made tamper-proof with an
HMAC.  Information that is sensitive can be encrypted with a strong
cipher like Blowfish.  It's not that hard.  The real issue with
cookie-storage is avoiding sending too much data back and forth.  In a
typical application, sessions contain a handful of database IDs and
uncommitted form data, so the size is reasonable.

- Perrin
From perrin at elem.com  Tue Mar 11 10:07:29 2008
From: perrin at elem.com (Perrin Harkins)
Date: Tue Mar 11 10:07:32 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <d69cc4a60803100846o33ac3b60oe3ac56184915a417@mail.gmail.com>
References: <20080310105638.GA7656@knight.local>
	<47D5346E.7050504@plusthree.com>
	<d69cc4a60803100627i14db5930gf6d0eafd3454d71e@mail.gmail.com>
	<66887a3d0803100828x6174a784ye39076a68f581a5e@mail.gmail.com>
	<d69cc4a60803100846o33ac3b60oe3ac56184915a417@mail.gmail.com>
Message-ID: <66887a3d0803110707k79db139ekdc1e90b68418d1d@mail.gmail.com>

On Mon, Mar 10, 2008 at 11:46 AM, Mark Fuller <azfuller@gmail.com> wrote:
>  BTW: I didn't understand the part in the Catalyst documentation saying
>  the benefit of sending the session in the cookie is that you don't
>  have to access the disk. I assume that's supposed to be a performance
>  benefit. But, after two encodings and an encryption, and two decodings
>  and a decryption? I don't see how that could be much of a performance
>  boost.

It's worth benchmarking, but it seems likely to me that even strong
encryption is faster than fetching data from a database.  Removing one
or more database hits from every page access could be significant.
Most web servers have tons of idle CPU because they're constantly
waiting for I/O operations.

The real win in my mind is scalability -- you no longer have to worry
about how to share the data across your cluster.  No matter how many
servers you add, your cost for session storage never goes up.

- Perrin
From azfuller at gmail.com  Tue Mar 11 10:52:29 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Tue Mar 11 10:52:31 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <20080310165403.GA9286@knight.local>
References: <20080310105638.GA7656@knight.local>
	<d69cc4a60803100606s46d5cb20l38a48f4963373bbe@mail.gmail.com>
	<20080310165403.GA9286@knight.local>
Message-ID: <d69cc4a60803110752xe637dbbn47d7e810db607ff@mail.gmail.com>

On Mon, Mar 10, 2008 at 9:54 AM, Ricardo SIGNES
<perl.cgiapp@rjbs.manxome.org> wrote:
>
>  I think the amount of brute force required would still be pretty darn brutal.

Doesn't it depend upon the operator's choice of passphrase? And,
whether tomorrow is the day a weakness is found in the encryption
method? (In 2003 the NSA said Rijaendel could be used for classified
data. In 2006, the NSA said it couldn't.).

>  I wouldn't use this for anything like banking or credit cards, but I feel
>  pretty okay about it for things like a Rubric login.

The problem (from my perspective) is that if it's encrypted *I* have
no idea what you're trying to store on *my* computer. Nor what
encryption method you've chosen (if any at all, it could be base 64
encoding to obfuscate the data), your diligence in choosing a
passphrase.

>  Probably what I'll do in the (near) future is have an n-day log of secrets,
>  generated daily.  The cookie will then be like
>
>   { generated: yyyymmdd, cookie: ciphertext }
>
>  You'll have to crack the secret within n days, which makes it even more
>  tedious.

I was thinking more along the lines of a cracked cookie being harmful
to me, not you. :)

This just doesn't seem like a good use of a cookie to me. It could be
a good use. But, as the person upon whose computer it is being placed
(which might be a public computer, et al), I can't tell if it's a good
use because it's encrypted. A lack of transparency into what's being
placed on (hopefully) my computer doesn't seem like a good thing. It
may make the operator's processing more efficient and scalable. But,
I'm old enough to remember people making that argument for storing
private information as hidden form fields 15 years ago.

Mark
From perl.cgiapp at rjbs.manxome.org  Tue Mar 11 11:19:40 2008
From: perl.cgiapp at rjbs.manxome.org (Ricardo SIGNES)
Date: Tue Mar 11 11:19:44 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <d69cc4a60803110752xe637dbbn47d7e810db607ff@mail.gmail.com>
References: <20080310105638.GA7656@knight.local>
	<d69cc4a60803100606s46d5cb20l38a48f4963373bbe@mail.gmail.com>
	<20080310165403.GA9286@knight.local>
	<d69cc4a60803110752xe637dbbn47d7e810db607ff@mail.gmail.com>
Message-ID: <20080311151940.GA15878@knight.local>

* Mark Fuller <azfuller@gmail.com> [2008-03-11T10:52:29]
> On Mon, Mar 10, 2008 at 9:54 AM, Ricardo SIGNES
> >  I wouldn't use this for anything like banking or credit cards, but I feel
> >  pretty okay about it for things like a Rubric login.
> 
> The problem (from my perspective) is that if it's encrypted *I* have
> no idea what you're trying to store on *my* computer. Nor what
> encryption method you've chosen (if any at all, it could be base 64
> encoding to obfuscate the data), your diligence in choosing a
> passphrase.

If you don't trust my ability to make security decisions, you shouldn't use
services I provide.  Period.  If I only stored a session key, and then looked
up sessions in Amazon S3, where I stored your credit card number in the clear,
with a password of "rjbs" you would never know.

One must make security decisions based on the reputation of the service
provider, because the implementation details will generally not be exposed.

> >  Probably what I'll do in the (near) future is have an n-day log of secrets,
> >  generated daily.  The cookie will then be like
> >
> >   { generated: yyyymmdd, cookie: ciphertext }
> >
> >  You'll have to crack the secret within n days, which makes it even more
> >  tedious.
> 
> I was thinking more along the lines of a cracked cookie being harmful
> to me, not you. :)

If cookie vulnerability means someone can alter someone else's data, it's bad
for the service provider AND the service consumer.  Am I missing something?

I guess someone could store child porn in encrypted cookies on users'
computers, but... 

What's the specific problem you're objecting to, here?

> This just doesn't seem like a good use of a cookie to me. It could be
> a good use. But, as the person upon whose computer it is being placed
> (which might be a public computer, et al), I can't tell if it's a good
> use because it's encrypted. A lack of transparency into what's being
> placed on (hopefully) my computer doesn't seem like a good thing. It
> may make the operator's processing more efficient and scalable. But,
> I'm old enough to remember people making that argument for storing
> private information as hidden form fields 15 years ago.

...but fifteen years ago, the data was still visible in the clear, so it was
obviously stupid for any use case where the connection was not secure end to
end.  I don't see a serious security vulnerability here, at least for services
that will not be attracting huge amounts of CPU-years of attack per day.

Is your objection just that you don't want me storing anything in your
browser's cookie jar that isn't plaintext or a serial number?

-- 
rjbs
From mpeters at plusthree.com  Tue Mar 11 11:22:18 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Tue Mar 11 11:25:05 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <20080311151940.GA15878@knight.local>
References: <20080310105638.GA7656@knight.local>	<d69cc4a60803100606s46d5cb20l38a48f4963373bbe@mail.gmail.com>	<20080310165403.GA9286@knight.local>	<d69cc4a60803110752xe637dbbn47d7e810db607ff@mail.gmail.com>
	<20080311151940.GA15878@knight.local>
Message-ID: <47D6A3AA.6000602@plusthree.com>

Ricardo SIGNES wrote:

> Is your objection just that you don't want me storing anything in your
> browser's cookie jar that isn't plaintext or a serial number?

Also, I'd like to make that point that a good unique session id (like one
generated form mod_unique_id) will be indistinguishable from some encrypted data
or some data structure. They need to be Base64 encoded (or similar) to be used
in HTTP headers anyway, so it's all plain text.

-- 
Michael Peters
Plus Three, LP

From azfuller at gmail.com  Tue Mar 11 11:34:22 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Tue Mar 11 11:34:26 2008
Subject: [cgiapp] enciphered-cookie-only sessions
In-Reply-To: <20080311151940.GA15878@knight.local>
References: <20080310105638.GA7656@knight.local>
	<d69cc4a60803100606s46d5cb20l38a48f4963373bbe@mail.gmail.com>
	<20080310165403.GA9286@knight.local>
	<d69cc4a60803110752xe637dbbn47d7e810db607ff@mail.gmail.com>
	<20080311151940.GA15878@knight.local>
Message-ID: <d69cc4a60803110834y3806de54sb3865dbce34ee309@mail.gmail.com>

On Tue, Mar 11, 2008 at 8:19 AM, Ricardo SIGNES
<perl.cgiapp@rjbs.manxome.org> wrote:
>  Is your objection just that you don't want me storing anything in your
>  browser's cookie jar that isn't plaintext ...

Yes. I thought I'd said that more than once. A unfortunate perception
exists among many that cookies are bad. IMO encrypting session data
and placing it in a cookie contributes to that perception. It doesn't
mean every usage is bad. But, it can be. The problem being that it's
not transparent for the recipient to make that determination.

I agree with you that worse things could be happening on the backend
(storing credit card numbers in clear text on a loosely secured
network-accessible device).

Mark
From szabgab at gmail.com  Thu Mar 13 16:45:34 2008
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu Mar 13 16:45:36 2008
Subject: [cgiapp] CGIApp Project Management
In-Reply-To: <1b9c12d0802121625r660693cfyc980bb2199d2193f@mail.gmail.com>
References: <BD564309-D5DE-4D8E-B0CE-14E9D08C16CF@genetics.utah.edu>
	<27517.210.54.245.44.1202848048.squirrel@mail.redbone.co.nz>
	<1b9c12d0802121625r660693cfyc980bb2199d2193f@mail.gmail.com>
Message-ID: <d8a74af10803131345l5b6953e8lb5cfb6af8c75a174@mail.gmail.com>

I am a bit late to this discussion but ...

On Wed, Feb 13, 2008 at 2:25 AM, Joshua Miller <unrtst@gmail.com> wrote:
>  Actually, we give each dev a range of 10 ports, so they can run multiple
>  versions of the app side by side. Just throw together a little apachectl
>  wrapper, and a base apache config, so they just have to include the base
>  config, and set a handful of vars to get their instance up.
>  Then they can start/stop their instance on their own, and no worries about
>  contaminated env or writing/reading someone elses files.

I guess you need to start/stop the serves as you are under mod_perl.
Do you need mod_perl specific things?

If not, is there any reason not to develop in plain CGI mode and then
use mod_perl
only in some integration (staging) server and in the live application?

I am asking just because that's what I am doing...

Gabor
From mpeters at plusthree.com  Thu Mar 13 16:48:56 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Thu Mar 13 16:52:36 2008
Subject: [cgiapp] CGIApp Project Management
In-Reply-To: <d8a74af10803131345l5b6953e8lb5cfb6af8c75a174@mail.gmail.com>
References: <BD564309-D5DE-4D8E-B0CE-14E9D08C16CF@genetics.utah.edu>	<27517.210.54.245.44.1202848048.squirrel@mail.redbone.co.nz>	<1b9c12d0802121625r660693cfyc980bb2199d2193f@mail.gmail.com>
	<d8a74af10803131345l5b6953e8lb5cfb6af8c75a174@mail.gmail.com>
Message-ID: <47D99338.6080201@plusthree.com>

Gabor Szabo wrote:

> If not, is there any reason not to develop in plain CGI mode and then
> use mod_perl
> only in some integration (staging) server and in the live application?

If you aren't using the mod_perl/Apache API then developing in CGI mode makes
sense. Although I wouldn't do all of your dev that way. I'd have a flag that
turns it on and off. For one, it's nice to be able to know your app functions in
mod_perl before launching it. And it's also nice if you're doing some
development related tasks that don't require code changes before every request
(like writing docs for the new version, taking screen shots, doing walkthroughs,
etc). It'd suck to demo a new version of something to your boss and have it be
slow just cause you're using CGI cause it's dev code.

-- 
Michael Peters
Plus Three, LP

From cgiapp at brad.memoryleak.org  Thu Mar 13 21:42:13 2008
From: cgiapp at brad.memoryleak.org (Bradley C Bailey)
Date: Thu Mar 13 21:42:21 2008
Subject: [cgiapp] CGI::Application::Dispatch Install Issues
In-Reply-To: <47D2DA62.3070504@plusthree.com>
References: <OF3256971B.F9F57EF0-ON86257405.00546303-86257405.00557C33@mgic.com>	<47D2D193.8010605@plusthree.com>
	<47D2DA62.3070504@plusthree.com>
Message-ID: <47D9D7F5.1080802@brad.memoryleak.org>

> Ok, not instead of trying to use the toolchain to install Module::Build and then
> Apache::Test (if you answered yes at the prompt) I'm just going to be really
> dumb. If you have Apache::Test on your machine I will use it and run the
> mod_perl tests as well as the CGI ones. Else I won't. And since apparently not
> everyone has upgraded their toolchain to include Module::Build I'll include a
> normal Makefile.PL in the distribution.

I do have Module::Build, but I just wanted to say that when I tried to 
use the Makefile.PL for version 2.13_02, I got the following error:

Couldn't open t/TEST.PL: No such file or directory at 
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Apache/TestMM.pm 
line 133.

I have Apache::Test 1.30.  It looks like the dist is missing the 
t/TEST.PL file?

Everything works with Module::Build.

Regards,
Bradley C Bailey

From shijialeee at yahoo.com  Thu Mar 13 23:55:56 2008
From: shijialeee at yahoo.com (James.Q.L)
Date: Thu Mar 13 23:55:58 2008
Subject: [cgiapp] code reuse.
Message-ID: <922542.31979.qm@web50109.mail.re2.yahoo.com>

Greetings,

I would like to seek opinions on the issue of reusing code. i am slowly finding common things that
i need to do within my C::A apps.  i have put the common codes into C::A plugin or just normal
module but i don't really like the way it is organized. 

one example is that there is event logging in every apps so i created a C::A::P::EventLogging,
then in my app's Base module i have something like the following. btw, Company is the top
namespace for shared libraries used or will be used in multiple apps.
	
	package MyAPP::Base;
	use Company::CAP::EventLogging;
	use Company::Util;
	use MyAPP::DB;

	sub cgiapp_prerun {
		
		my $dbh = MyApp::DB->dbh;
		my $uuid = Company::Util->uuid( { dbh => $dbh, 
								uname => $ENV{REMOTE_USER},
		} );	
		$self->param('uuid', $uuid);
		$self->elog_config( { dbh  => $dbh, 
						uuid => $uuid,
		} );
	
		# then i can do 
		$self->elog("blabla");	
	}

two things that i don't like the above code are
	
1. passing $dbh to every shared lib that needs it. the $dbh is coming from each app's MyAPP::DB
module. 
2. $uuid (there are other properties too)  is used in other places (controller and model ) in the
app as well. in controller i just  call $self->param to get it but for controller i have to pass
it as an extra parameter.

i can't think of a good way to tackle my issues.. what's your opinion?




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

From lackhoff at zbmed.uni-koeln.de  Fri Mar 14 08:14:21 2008
From: lackhoff at zbmed.uni-koeln.de (Michael Lackhoff)
Date: Fri Mar 14 08:14:25 2008
Subject: [cgiapp] Cannot return custom ErrorDocument with
	CGI::Application::Dispatch
Message-ID: <47DA7A2D.25616.3422EBF3@lackhoff.zbmed.uni-koeln.de>

Hello,

I am trying to produce a nice error page when something is going wrong 
but whatever I try I only get this:

  Not Found
  The requested URL /demo/home/not_a_runmode was not found on this
  server.
  Additionally, a 404 Not Found error was encountered while trying to  
  use an ErrorDocument to handle the request

First I tried it with the error_document parameter in dispatch_args:
error_document => '"Oopss... HTTP Error #%s', # from the docs

Then I tried it the Apache way in httpd.conf:
ErrorDocument 404 /myerror404.html

As I said, the result is always the same, namely the text quoted above, 
no custom error page/string.

Just for reference, here is the relevant part of my httpd.conf:
<Location /demo>
    SetHandler perl-script
    PerlHandler Demo::CAP::Dispatch
    ErrorDocument 404 /myerror404.html
</Location>

And here is the complete Demo::CAP::Dispatch:

package Demo::CAP::Dispatch;

use base 'CGI::Application::Dispatch';

sub dispatch_args {
    return {
        prefix  => 'Demo::CAP',
        error_document => '"Oopss... HTTP Error #%s',
        args_to_new => {
            PARAMS => {
                cssloc   => '/demoplain',
                jsloc    => '/demoplain',
            },
        },
        table   => [
            ''                => { app => 'home', rm => 'start' },
            ':app/:rm'        => { },
            ':app/:rm/:nr'    => { },
        ],
    };
}

1;

Existing runmodes do work (at least with perl-script as above, not with 
'SetHandler modperl' but that is another question). It is just the 
error message for missing runmodes I am after here.

Any ideas what is going wrong? 
A working example using CAP::Dispatch with mod_perl would be great, 
too. I could feel my way from there.

Thanks
-Michael

From slavash at aha.ru  Fri Mar 14 09:21:38 2008
From: slavash at aha.ru (Vyacheslav Shevelyov)
Date: Fri Mar 14 10:05:49 2008
Subject: [cgiapp] Re: Cannot return custom ErrorDocument
	withCGI::Application::Dispatch
References: <47DA7A2D.25616.3422EBF3@lackhoff.zbmed.uni-koeln.de>
Message-ID: <frdu8g$121$1@ger.gmane.org>


"Michael Lackhoff" <lackhoff@zbmed.uni-koeln.de> ???????/???????? ? ???????? 
?????????: news:47DA7A2D.25616.3422EBF3@lackhoff.zbmed.uni-koeln.de...
> Hello,
>
> I am trying to produce a nice error page when something is going wrong
> but whatever I try I only get this:

Under MOD_PERL error_document parameter works only as URL.




From azfuller at gmail.com  Fri Mar 14 13:13:17 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Fri Mar 14 13:13:21 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <922542.31979.qm@web50109.mail.re2.yahoo.com>
References: <922542.31979.qm@web50109.mail.re2.yahoo.com>
Message-ID: <d69cc4a60803141013p652d0e27nb4d0d02ebf0ff1b9@mail.gmail.com>

On Thu, Mar 13, 2008 at 8:55 PM, James.Q.L <shijialeee@yahoo.com> wrote:
>  I would like to seek opinions on the issue of reusing code. i am slowly finding common things
> that  i need to do within my C::A apps.  i have put the common codes into C::A plugin or just
> normal  module but i don't really like the way it is organized.

1. You're storing $dbh and $uuid as a param in C::A. Why are you
passing them as parameters instead of retrieving them from param?

You can also use C::A::Plugin::Stash which is like a front-end to
C::A's param method. It makes it easier to use (IMO) because it feels
like you're working directly with a variable (not a method).

2. $uuid needs to be specific to this instance. But, $dbh might fit
better in cgiapp_init, and stored as a class variable (of your
package) so that, if you use some form persistence (mod_perl,
fcgi/fastcgi, speedyCGI/persistentPerl/perperl) you'd only load and
connect once. (But, you have to handle errors and reconnections due to
timeouts.).

3. Since you haven't made the step (yet) to make "Company::Util" an
object, you could let it  store $uuid in its own namespace (as an
"our" variable?) and then access it directly wherever needed
($Company::Util::uuid). That's probably not the best practice. But,
it's part of the evolution from subroutines to objects (which I think
is the path you're on).

I went through this 4-5 years ago. I asked about it on Perlmonks
because it's more of a general Perl/style topic. I was told that I was
going through a normal transition from collecting related routines
into subroutines, into namespaces (modules) and finally objects. It's
still not always clear to me where things belong.

Mark
From david at axiombox.com  Fri Mar 14 17:37:01 2008
From: david at axiombox.com (David Moreno)
Date: Fri Mar 14 17:37:04 2008
Subject: [cgiapp] URL rewriting...
In-Reply-To: <fqn4rc$72u$1@ger.gmane.org>
References: <fqn4rc$72u$1@ger.gmane.org>
Message-ID: <144c024a0803141437p501ccc7etd7190bf7209cf913@mail.gmail.com>

On Wed, Mar 5, 2008 at 5:54 PM, Robert Hicks <sigzero@gmail.com> wrote:
> I haven't a clue on this one. I do the standard CA thing with page names:
>
>  ?rm=home
>  ?rm=contact
>
>  How do I do a URL re-write that makes the first one /home/ and the
>  second one /contact/ ?
>
>  Pointers would help...you don't have to give me the whole answer. I like
>  to learn.  :-)

I usually use modrewrite on an .htaccess with something like:

RewriteRule ^(.*)/$ /my.cgi?rm=$1

Yes, you can refine a lot the regex, but that's simply out of scope of
this reply ;)

-- 
David Moreno - http://www.damog.net/
 Yes, you can.
From shijialeee at yahoo.com  Sun Mar 16 19:31:21 2008
From: shijialeee at yahoo.com (James.Q.L)
Date: Sun Mar 16 19:31:24 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <d69cc4a60803141013p652d0e27nb4d0d02ebf0ff1b9@mail.gmail.com>
Message-ID: <844503.80198.qm@web50103.mail.re2.yahoo.com>

--- Mark Fuller <azfuller@gmail.com> wrote:

> 1. You're storing $dbh and $uuid as a param in C::A. Why are you
> passing them as parameters instead of retrieving them from param?
> 

I store ONLY $uuid in param because i need it in other controller. i am passing $dbh to Company::
modules because these modules are not inherited from C::A. 

> 2. $uuid needs to be specific to this instance. But, $dbh might fit
> better in cgiapp_init, and stored as a class variable (of your
> package) so that, if you use some form persistence (mod_perl,
> fcgi/fastcgi, speedyCGI/persistentPerl/perperl) you'd only load and
> connect once. (But, you have to handle errors and reconnections due to
> timeouts.).
> 

i am using DBI's connect_cached which supposed to return the same $dbh under persistent env.

> 3. Since you haven't made the step (yet) to make "Company::Util" an
> object, you could let it  store $uuid in its own namespace (as an
> "our" variable?) and then access it directly wherever needed
> ($Company::Util::uuid). That's probably not the best practice. But,
> it's part of the evolution from subroutines to objects (which I think
> is the path you're on).
> 

i like to define $uuid, $dbh in a central place and have it shared with Company::XX Company::YY
etc, regardless doing it in the object or class way. but i can't figure out how.

> Mark
> 

thanks,

James.


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
From azfuller at gmail.com  Sun Mar 16 19:59:12 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Sun Mar 16 19:59:15 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <844503.80198.qm@web50103.mail.re2.yahoo.com>
References: <d69cc4a60803141013p652d0e27nb4d0d02ebf0ff1b9@mail.gmail.com>
	<844503.80198.qm@web50103.mail.re2.yahoo.com>
Message-ID: <d69cc4a60803161659i3d0645faqc0ab3b1f8b00ba95@mail.gmail.com>

On Sun, Mar 16, 2008 at 4:31 PM, James.Q.L <shijialeee@yahoo.com> wrote:
>
>I store ONLY $uuid in param because i need it in other controller. i
am passing $dbh to
>Company:: modules because these modules are not inherited from C::A.

The example your provided showed them being passed as parameters to
$self->methods() which have access to the param method..

If you're passing them to true subroutines (not methods) there's no
way around that except to begin refactoring your code into objects.
That's the problem I had a few years ago and found myself bundling
things into one hash which could be passed around (a lot like an
object). Or, creating modules to hold the data belonging to that
namespace within that namespace (a lot like an object). And then,
voila!, a module with a hash (an object).

>  i like to define $uuid,

I might be missing the point, but what's wrong with storing $uuid in
Company::Util as an "our" variable and accessing it from anywhere as
$Company::Util::uuid ?

I'm not sure that's the right thing to do. But, it's what you're
asking for. If you're going through what I did, once you do that I bet
you proceed to an object. Or, making your subroutines methods.

Maybe you should post a different example? It sounds like the one you
posted didn't represent the problem you're having?

Mark
From shijialeee at yahoo.com  Mon Mar 17 10:05:12 2008
From: shijialeee at yahoo.com (James.Q.L)
Date: Mon Mar 17 10:05:16 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <d69cc4a60803161659i3d0645faqc0ab3b1f8b00ba95@mail.gmail.com>
Message-ID: <791181.1023.qm@web50105.mail.re2.yahoo.com>


--- Mark Fuller <azfuller@gmail.com> wrote:

> On Sun, Mar 16, 2008 at 4:31 PM, James.Q.L <shijialeee@yahoo.com> wrote:
> >
> >I store ONLY $uuid in param because i need it in other controller. i
> am passing $dbh to
> >Company:: modules because these modules are not inherited from C::A.
> 
> The example your provided showed them being passed as parameters to
> $self->methods() which have access to the param method..
> 
> If you're passing them to true subroutines (not methods) there's no
> way around that except to begin refactoring your code into objects.
> That's the problem I had a few years ago and found myself bundling
> things into one hash which could be passed around (a lot like an
> object). Or, creating modules to hold the data belonging to that
> namespace within that namespace (a lot like an object). And then,
> voila!, a module with a hash (an object).

i would like to an example of this.

> 
> >  i like to define $uuid,
> 
> I might be missing the point, but what's wrong with storing $uuid in
> Company::Util as an "our" variable and accessing it from anywhere as
> $Company::Util::uuid ?
> 

correct me if i am wrong. that won't work under mod_perl. because our $uuid is a global package
variable and shared by all instances. 

> I'm not sure that's the right thing to do. But, it's what you're
> asking for. If you're going through what I did, once you do that I bet
> you proceed to an object. Or, making your subroutines methods.
> 
> Maybe you should post a different example? It sounds like the one you
> posted didn't represent the problem you're having?
>

what i want is to setup $uuid and $dbh for the Company:: modules so that i can do

use base 'CGI::Application';
use Company::CAP::EventLogging; # a plugin for CGI::Application

sub cgiapp_init { 
  # init Company::Base
  $company = Company::Base->new();
  $company->dbh( MyApp::DB->dbh );
  $company->user($ENV{REMOTE_USER}); 
  # then somehow all my Company:: can start to use the $dbh etc.. 
}

sub method { 
  shift->elog("log this");
}

this is probably more of a OO design and mod_perl related question.. probably i better seek help
from perlmonk or mod_perl list..
 
> Mark

thanks,

James.



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

From mpeters at plusthree.com  Mon Mar 17 10:16:53 2008
From: mpeters at plusthree.com (Michael Peters)
Date: Mon Mar 17 10:19:49 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <791181.1023.qm@web50105.mail.re2.yahoo.com>
References: <791181.1023.qm@web50105.mail.re2.yahoo.com>
Message-ID: <47DE7D55.60204@plusthree.com>

James.Q.L wrote:

>> I might be missing the point, but what's wrong with storing $uuid in
>> Company::Util as an "our" variable and accessing it from anywhere as
>> $Company::Util::uuid ?
>>
> 
> correct me if i am wrong. that won't work under mod_perl. because our $uuid is a global package
> variable and shared by all instances.

Does the UUID change per application instance? If so, then make it a method
instead of a variable. Then you can decide which actual uuid to return based on
how it's called.

> what i want is to setup $uuid and $dbh for the Company:: modules 

We have a large application that runs under mod_perl that needs to be have
differently for each site that it's serving. It basically comes down to having
something in your httpd.conf that you can read to determine which client you're
serving. Then we use that to look up the relevant section in the configuration
file to then be able to create the DB handle. Something like this:

  PerlSetVar UUID blahblah

Then your Company::Util::uuid() method will return that var and your
Company::Util::dbh() method could read that and then look up in your
configuration file to see which dbname/user/pw are associated with that UUID and
then return the db handle.

Or something like that.
-- 
Michael Peters
Plus Three, LP

From azfuller at gmail.com  Mon Mar 17 13:07:12 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Mon Mar 17 13:07:14 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <791181.1023.qm@web50105.mail.re2.yahoo.com>
References: <d69cc4a60803161659i3d0645faqc0ab3b1f8b00ba95@mail.gmail.com>
	<791181.1023.qm@web50105.mail.re2.yahoo.com>
Message-ID: <d69cc4a60803171007g33638fa0w15b55152576659d6@mail.gmail.com>

On Mon, Mar 17, 2008 at 7:05 AM, James.Q.L <shijialeee@yahoo.com> wrote:
>  > I might be missing the point, but what's wrong with storing $uuid in
>  > Company::Util as an "our" variable and accessing it from anywhere as
>  > $Company::Util::uuid ?
>
>  correct me if i am wrong. that won't work under mod_perl. because our $uuid is a global
> package  variable and shared by all instances.

I don't understand how that works. If I have a simple script (in
mod_perl) and "require Some::Module.pm," is it being compiled into a
standalone package? If 14 other scripts require it they all get the
same compiled package (in whatever state the others left it)?

I thought it was unique to the script that required it. It seems like
it would create bottlenecks if Some::Module.pm did a lot of
processing, blocking other scripts that required it (and share it?)
and are now calling it.

If you (or anyone) can confirm that's how it works I'd appreciate it.

>  what i want is to setup $uuid and $dbh for the Company:: modules so that i can do
>
>  use base 'CGI::Application';
>  use Company::CAP::EventLogging; # a plugin for CGI::Application
>
>  sub cgiapp_init {
>   # init Company::Base
>   $company = Company::Base->new();
>   $company->dbh( MyApp::DB->dbh );
>   $company->user($ENV{REMOTE_USER});
>   # then somehow all my Company:: can start to use the $dbh etc..
>  }
>
>  sub method {
>   shift->elog("log this");
>  }

You're calling "elog" as a method? In that case you could store $dbh
(etc.) in C::A's param method. Then elog (etc.) can retrieve it using
the param method?

Mark
From lhernsen1015 at wowway.com  Mon Mar 17 14:31:35 2008
From: lhernsen1015 at wowway.com (Lou Hernsen)
Date: Mon Mar 17 13:35:30 2008
Subject: [cgiapp] Newbe has ? about modules and grapihic
References: <d69cc4a60803161659i3d0645faqc0ab3b1f8b00ba95@mail.gmail.com><791181.1023.qm@web50105.mail.re2.yahoo.com>
	<d69cc4a60803171007g33638fa0w15b55152576659d6@mail.gmail.com>
Message-ID: <000f01c8885d$2923b080$6401a8c0@lousmaster>

I want to know how I can layer pictures on top of each other like in a paint
program.

I have picture1.gif   picture2.gif   and picture3.gif and I want to put 1 on
top of 2 on top of 3.

I know I have to use transparent backgrounds or a masks.... but I have no
clue if it can be done
in an module before sending it out to a web page.

Currently I am layering tables with backgrounds to do this.

Any help is appreciated.
I hope this is on topic enuff.. if not just ignore it i guess.

Lou

From cgi-application at howlingfrog.com  Mon Mar 17 13:40:08 2008
From: cgi-application at howlingfrog.com (Graham TerMarsch)
Date: Mon Mar 17 13:40:12 2008
Subject: [cgiapp] Q: Authz, but only when user is Authenticated...
Message-ID: <200803171040.09057.cgi-application@howlingfrog.com>

Didn't get any feedback on this the first time around, so I thought I'd 
repost.

Anyone else doing similar and care to comment?

----------------------------------------------------------------------
With the recent release of CAP::Authz 0.07, I've started going back through my 
existing apps and updating them to use the "authz_runmodes()" instead of my 
custom Authz plugins which did something similar.

While doing this, however, I've run into a scenario that I thought I'd ask for 
some input on...

In most of the apps I'm working with right now, Authz is only useful if I've 
got an Authenticated user; if the user hasn't logged in then there's no point 
in even checking for Authz as I really want to show them a login page first.  
My custom Authz plugins used to check this for me, but I'm trying to find a 
simpler way to get this working with the new version of CAP::Authz so I can 
pitch my custom code.

So, I load up CAP::Authen and CAP::Authz in my App superclass and the prerun 
hooks get invoked in order (authen first, then authz).  However... if they 
both fail (user isn't logged in, so I obviously fail authz), CAP::Authz 
calls "prerun_mode()" last and overrides the rm that was set by CAP::Authen 
to trigger the login screen.

I've got a few possible ideas for working around this, but wanted to find out 
what others are doing...

1) Load CAP::Authz first.  That way, even if Authz fails, CAP::Authen would be 
the last one to call "prerun_mode()" and the user would get shown the login 
page.  This works, but feels counter-intuitive; I'm always thinking that I 
want Authen to run first so I load that plugin first.

2) Add a new "REQUIRES_AUTHEN" option to CAP::Authz, so that if its unable to 
even figure out what the username is then it doesn't even bother doing an 
Authz check.

What are you guys doing when you want similar behaviour?

------

FWIW, some minimal code to show my setup would go like this...

  class MY::App;
  use base qw(CGI::Application);
  use CGI::Application::Plugin::Authentication;
  use CGI::Application::Plugin::Authorization;
  sub cgiapp_init {
    my $self = shift;
    $self->authen->config( ... );
    $self->authz->config( ... );
  }

  class MY::DerivedApp;
  use base qw(MY::App);
  sub setup {
    my $self = shift;
    $self->authen->protected_runmodes( ':all' );
    $self->authz->authz_runmodes( ':all' => 'admin' );
  }

Gist of the setup is that the superclass sets up the global Authen/Authz 
config and the drivers, while each derived app then sets up the list of 
Authen protected runmodes and the Authz requirements for the modes.

-- 
Graham TerMarsch
From shijialeee at yahoo.com  Mon Mar 17 16:00:02 2008
From: shijialeee at yahoo.com (James.Q.L)
Date: Mon Mar 17 16:00:06 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <d69cc4a60803171007g33638fa0w15b55152576659d6@mail.gmail.com>
Message-ID: <614947.30323.qm@web50112.mail.re2.yahoo.com>


--- Mark Fuller <azfuller@gmail.com> wrote:

> On Mon, Mar 17, 2008 at 7:05 AM, James.Q.L <shijialeee@yahoo.com> wrote:
> >  > I might be missing the point, but what's wrong with storing $uuid in
> >  > Company::Util as an "our" variable and accessing it from anywhere as
> >  > $Company::Util::uuid ?
> >
> >  correct me if i am wrong. that won't work under mod_perl. because our $uuid is a global
> > package  variable and shared by all instances.
> 
> I don't understand how that works. If I have a simple script (in
> mod_perl) and "require Some::Module.pm," is it being compiled into a
> standalone package? If 14 other scripts require it they all get the
> same compiled package (in whatever state the others left it)?
> 
> I thought it was unique to the script that required it. It seems like
> it would create bottlenecks if Some::Module.pm did a lot of
> processing, blocking other scripts that required it (and share it?)
> and are now calling it.
> 
> If you (or anyone) can confirm that's how it works I'd appreciate it.
> 

i think you are right. it is fine as long as the global variable is explicitly initialized.

sorry i misled you.

> >  what i want is to setup $uuid and $dbh for the Company:: modules so that i can do
> >
> >  use base 'CGI::Application';
> >  use Company::CAP::EventLogging; # a plugin for CGI::Application
> >
> >  sub cgiapp_init {
> >   # init Company::Base
> >   $company = Company::Base->new();
> >   $company->dbh( MyApp::DB->dbh );
> >   $company->user($ENV{REMOTE_USER});
> >   # then somehow all my Company:: can start to use the $dbh etc..
> >  }
> >
> >  sub method {
> >   shift->elog("log this");
> >  }
> 
> You're calling "elog" as a method? In that case you could store $dbh
> (etc.) in C::A's param method. Then elog (etc.) can retrieve it using
> the param method?
> 

i have asked a question on perlmonks with a better example. see
http://perlmonks.org/?node_id=674601

> Mark
> 

thanks,

James.


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
From azfuller at gmail.com  Mon Mar 17 16:07:02 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Mon Mar 17 16:07:06 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <614947.30323.qm@web50112.mail.re2.yahoo.com>
References: <d69cc4a60803171007g33638fa0w15b55152576659d6@mail.gmail.com>
	<614947.30323.qm@web50112.mail.re2.yahoo.com>
Message-ID: <d69cc4a60803171307h9d53d11y959b2dab5ae04564@mail.gmail.com>

On Mon, Mar 17, 2008 at 1:00 PM, James.Q.L <shijialeee@yahoo.com> wrote:
>  i think you are right. it is fine as long as the global variable is explicitly initialized.

No problem. So, what I was thinking is that you could initialize the
"our $uuid" with specific method you'd call from cgiapp_init (like
initialize_uuid). After that you can access $uuid as
$Company::Module_name::uuid from anywhere.

That's what I was trying to describe. It might be better to create an
accessor method like Michael suggested.

>  i have asked a question on perlmonks with a better example. see
>  http://perlmonks.org/?node_id=674601

Thanks. I'll follow that.

Mark
From lecar_red at yahoo.com  Mon Mar 17 16:25:56 2008
From: lecar_red at yahoo.com (Lee Carmichael)
Date: Mon Mar 17 16:25:58 2008
Subject: [cgiapp] Q: Authz, but only when user is Authenticated...
Message-ID: <910157.93410.qm@web31414.mail.mud.yahoo.com>

Hello Graham,

I just ran into this same problem last week. I was just crafting an email about it but found it hard to explain. You did a great job :)

> So, I load up CAP::Authen and CAP::Authz in my App superclass and the prerun 
> hooks get invoked in order (authen first, then authz).  However... if they 
> both fail (user isn't logged in, so I obviously fail authz), CAP::Authz 
> calls "prerun_mode()" last and overrides the rm that was set by CAP::Authen 
> to trigger the login screen.

This is a problem with any prerun callbacks. The last one run will be the one that sets the 'prerun_mode'. 

I did find that one plugin (Dispatch I think) that was being aware and checking to make sure that prerun_mode wasn't set yet. I'm not sure this is a great choice since it assumes that plugin authors will be aware of this and code around it. It just seems wrong to me...

> I've got a few possible ideas for working around this, but wanted to find out 
> what others are doing...
> 
> 1) Load CAP::Authz first.  That way, even if Authz fails, CAP::Authen would be 
> the last one to call "prerun_mode()" and the user would get shown the login 
> page.  This works, but feels counter-intuitive; I'm always thinking that I 
> want Authen to run first so I load that plugin first.

I didn't like this one either.

> 2) Add a new "REQUIRES_AUTHEN" option to CAP::Authz, so that if its unable to 
> even figure out what the username is then it doesn't even bother doing an 
> Authz check.

I like this. 

> What are you guys doing when you want similar behaviour?

I needed a really quick solution, so I added the following to my code until a better long term solution could be determined:

(prerun_mode could have been $self->auth->username too)

package My::WebApp;

## ..snip...
my @protected_modes = qw( page1 page2 );

sub cgiapp_prerun {
    my $self = shift;

    if ( !$self->prerun_mode ) {
        ## validate user authz stuff
        $self->authz->authz_runmodes( map { $_ => 'pxdesk' }
                @protected_runmodes );

        ## this is a bit strange but has to due with calling stuff
        ## I would expect: $self->authz->prerun_callback too...
        $self->CGI::Application::Plugin::Authorization::prerun_callback();
    }
}

In my case, I need to have some other prerun code still run so I just excluded the authz code. 

Overall, I think CA should handle this a bit better, but I'm not sure how since that call_hook code is really well separated and has a clean design. It seems wrong to 'mess' it up for this one case.

Maybe it would be good to have the callback throw an exception that would tell CA to stop processing other callbacks? But I could envision situations where the app may want other callbacks to still be called anyway like mine above :) Today the callback code will just die if it sees an exception. Maybe 'prerun_mode' could only be set once inside the prerun callbacks, first one to set it gets it. 

Other ideas?

Take Care,

Lee







From azfuller at gmail.com  Mon Mar 17 16:34:15 2008
From: azfuller at gmail.com (Mark Fuller)
Date: Mon Mar 17 16:34:18 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <614947.30323.qm@web50112.mail.re2.yahoo.com>
References: <d69cc4a60803171007g33638fa0w15b55152576659d6@mail.gmail.com>
	<614947.30323.qm@web50112.mail.re2.yahoo.com>
Message-ID: <d69cc4a60803171334m4ecc8bb5gdebfa3926bc73f3d@mail.gmail.com>

James,

Another thought. If these routines are meant to be reused among
various C::A applications, have you considered making (one or more)
superclass that you're application is a base of? Like the following?
This way you could have myapp1, myapp2, etc. that inherit from
"superclassMyApp". Which inherits from "superclassWebApp." With a
hierarchy like this you could keep extremely common things in the
highest level. Things that are application specific in lower levels.
You're dbh, uuid and logging routines might go in the top-most level.

===========
package myapp;

use base 'superclassMyApp';

[Methods specific to your application, like setup and actual run modes].

etc...

1;
===========

package superclassMyApp;

use base 'superclassWebApp';

[common methods. Maybe cgiapp_init goes here.]

1;
===========

package superclassWebApp;

use base 'CGI::Application';

[even more common methods. Maybe cgiapp_get_query goes here if you're
using CGI::Simple.]

1;
============
From cgi-application at howlingfrog.com  Mon Mar 17 17:14:42 2008
From: cgi-application at howlingfrog.com (Graham TerMarsch)
Date: Mon Mar 17 17:14:47 2008
Subject: [cgiapp] Q: Authz, but only when user is Authenticated...
In-Reply-To: <910157.93410.qm@web31414.mail.mud.yahoo.com>
References: <910157.93410.qm@web31414.mail.mud.yahoo.com>
Message-ID: <200803171414.43856.cgi-application@howlingfrog.com>

On Monday 17 March 2008 1:25 pm, Lee Carmichael wrote:
> I just ran into this same problem last week. I was just crafting an email
> about it but found it hard to explain. You did a great job :)
[.....snip.....]

> Overall, I think CA should handle this a bit better, but I'm not sure how
> since that call_hook code is really well separated and has a clean design.
> It seems wrong to 'mess' it up for this one case.
>
> Maybe it would be good to have the callback throw an exception that would
> tell CA to stop processing other callbacks? But I could envision situations
> where the app may want other callbacks to still be called anyway like mine
> above :) Today the callback code will just die if it sees an exception.
> Maybe 'prerun_mode' could only be set once inside the prerun callbacks,
> first one to set it gets it.

Oooh, now THAT'S an idea...

If "prerun_mode()" gets called multiple times, only the -FIRST- guy to set it 
gets to actually change the value.

Would probably be a simple change to make too, but at the same time I'm pretty 
sure that it'd break someones existing code.

That said, what if we allow this behaviour to be controlled via some sort of 
option, which could be set either via a parameter when calling "new()" or 
during initial app setup (e.g. before "prerun").  Default would be to stick 
with the existing behaviour, but by setting some sort of "prerun_first_only" 
flag/thingy we could force "prerun_mode()" to only keep the first value.

Seemed quick enough to do, so for fun I've whipped up the following UNTESTED 
patch to CGI::Application to add a new "prerun_mode_first_only()" method.

I haven't tested this patch at all, bit it might be suitable for discussion 
purposes; it keeps the existing CGI::App behaviour but adds a new option to 
help control it for those times when we want to do it backwards.

-- 
Graham TerMarsch
Howling Frog Internet Development, Inc.
From dan.horne at redbone.co.nz  Mon Mar 17 17:58:21 2008
From: dan.horne at redbone.co.nz (Dan Horne)
Date: Mon Mar 17 17:58:19 2008
Subject: [cgiapp] code reuse.
In-Reply-To: <d69cc4a60803171334m4ecc8bb5gdebfa3926bc73f3d@mail.gmail.com>
References: <d69cc4a60803171007g33638fa0w15b55152576659d6@mail.gmail.com><614947.30323.qm@web50112.mail.re2.yahoo.com>
	<d69cc4a60803171334m4ecc8bb5gdebfa3926bc73f3d@mail.gmail.com>
Message-ID: <002601c8887a$04123970$6403a8c0@rdbnnote01>

Some people argue that with an MVC architecture, the database handle should
never reside in the controller, and should only be accessible in the model,
e.g.

http://www.oreillynet.com/onlamp/blog/2007/06/what_is_mvc.html

I'd be interested to know how other C::A people implement this in their
apps.

> -----Original Message-----
> From: cgiapp-bounces@lists.erlbaum.net [mailto:cgiapp-
> bounces@lists.erlbaum.net] On Behalf Of Mark Fuller
> Sent: Tuesday, 18 March 2008 9:34 a.m.
> To: CGI Application
> Subject: Re: [cgiapp] code reuse.
> 
> James,
> 
> Another thought. If these routines are meant to be reused among
> various C::A applications, have you considered making (one or more)
> superclass that you're application is a base of? Like the following?
> This way you could have myapp1, myapp2, etc. that inherit from
> "superclassMyApp". Which inherits from "superclassWebApp." With a
> hierarchy like this you could keep extremely common things in the
> highest level. Things that are application specific in lower levels.
> You're dbh, uuid and logging routines might go in the top-most level.
> 
> ===========
> package myapp;
> 
> use base 'superclassMyApp';
> 
> [Methods specific to your application, like setup and actual run modes].
> 
> etc...
> 
> 1;
> ===========
> 
> package superclassMyApp;
> 
> use base 'superclassWebApp';
> 
> [common methods. Maybe cgiapp_init goes here.]
> 
> 1;
> ===========
> 
> package superclassWebApp;
> 
> use base 'CGI::Application';
> 
> [even more common methods. Maybe cgiapp_get_query goes here if you're
> using CGI::Simple.]
> 
> 1;
> ============
> 
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################


From cgi-application at howlingfrog.com  Mon Mar 17 18:45:39 2008
From: cgi-application at howlingfrog.com (Graham TerMarsch)
Date: Mon Mar 17 18:45:43 2008
Subject: [cgiapp] Q: Authz, but only when user is Authenticated...
In-Reply-To: <200803171414.43856.cgi-application@howlingfrog.com>
References: <910157.93410.qm@web31414.mail.mud.yahoo.com>
	<200803171414.43856.cgi-application@howlingfrog.com>
Message-ID: <200803171545.40564.cgi-application@howlingfrog.com>

On Monday 17 March 2008 2:14 pm, Graham TerMarsch wrote:
> Seemed quick enough to do, so for fun I've whipped up the following
> UNTESTED patch to CGI::Application to add a new "prerun_mode_first_only()"
> method.
>
> I haven't tested this patch at all, bit it might be suitable for discussion
> purposes; it keeps the existing CGI::App behaviour but adds a new option to
> help control it for those times when we want to do it backwards.

Hmmm.... looks like my patch got stripped.  Oh well...

Needless to say, this type of update to CGI::App to do this isn't that big; 
the "diff -u" output is only 3kbytes.

-- 
Graham TerMarsch
Howling Frog Internet Development, Inc.
From michael at petnuch.com  Tue Mar 18 00:20:23 2008
From: michael at petnuch.com (Michael Petnuch)
Date: Tue Mar 18 00:20:31 2008
Subject: [cgiapp] Function CGI::Application Code
In-Reply-To: <d69cc4a60803171007g33638fa0w15b55152576659d6@mail.gmail.com>
References: <d69cc4a60803161659i3d0645faqc0ab3b1f8b00ba95@mail.gmail.com>
	<791181.1023.qm@web50105.mail.re2.yahoo.com>
	<d69cc4a60803171007g33638fa0w15b55152576659d6@mail.gmail.com>
Message-ID: <2D05DCA8-533D-49E6-BCA9-57112D0DDB5E@petnuch.com>

Evening,

I have been a CGI::Application follower for quite a while now.  I  
used it to create the engine off which my personal website/blog/ 
everything site runs.  Back when I first started the documentation  
was not as good as it is now and it took me a while to get everything  
started.  But once I did I found how easily and extensible I could  
make my website.

So I figured that I would share my work with others.  All my code has  
been placed up on websvn and is publicly viewable.  I stole a bunch  
of thumbnailing code from somewhere and I don't remember because it  
worked better than mine (it was from some perl modules). So I might  
have to take that down.

But other than that, the codes and ideas/implementation are the  
result of many hours/cokes/and chinese food takeout on my days off  
(and sometimes during the week).

In the code you will find a fully function bloging type software  
complete with user registration and access control.  All entries are  
populated into a database that is accessed using Class::DBI.  The  
website HTML is  separate from the Perl using Template::Toolkit.

You will also find a slightly incomplete implementation of a photo  
gallery.  It is incomplete because I have yet to figure out a way to   
allow people to submit photos via that site that is elegant (ala  
flickr) because my Web 2.0 skills are non-existant.  Right now I have  
a separate perl script that I use to populate the database.  All  
imports are handled via CGI::Uplaoder.

The site uses a lot more modules as well, too many to discuses here  
(unless someone asks about something specific).

Websvn Link:  http://websvn.petnuch.com

Enjoy,
Michael

P.S. If you have any comments about how/why I did anything feel free  
to ask. I am not saying that what I did is the best approach, but it  
work and will be a good learning tool for anyone new to usign  
CGIAPP!  Goodluck
From jesse at erlbaum.net  Thu Mar 20 08:41:47 2008
From: jesse at erlbaum.net (Jesse Erlbaum)
Date: Thu Mar 20 08:42:53 2008
Subject: [cgiapp] Function CGI::Application Code
In-Reply-To: <2D05DCA8-533D-49E6-BCA9-57112D0DDB5E@petnuch.com>
References: <d69cc4a60803161659i3d0645faqc0ab3b1f8b00ba95@mail.gmail.com><791181.1023.qm@web50105.mail.re2.yahoo.com><d69cc4a60803171007g33638fa0w15b55152576659d6@mail.gmail.com>
	<2D05DCA8-533D-49E6-BCA9-57112D0DDB5E@petnuch.com>
Message-ID: <F3690AC81E5390499D4723777E499F9905391EDE@34093-EVS1C1.exchange.rackspace.com>

Hi Michael --

> So I figured that I would share my work with others.  All my code has
> been placed up on websvn and is publicly viewable.


Thanks for posting that.  It looks like a solid and large body of code, which could be very instructional for CGI-App developers -- old and new alike.

Warmest regards,

-Jesse-

?
Jesse Erlbaum
The Erlbaum Group, LLC
817 Broadway, 10th floor
New York, NY 10003
212-684-6161 (office)
917-647-3059 (mobile)
212-684-6226 (fax)
jesse@erlbaum.net



From jaldhar at braincells.com  Sun Mar 23 10:26:31 2008
From: jaldhar at braincells.com (Jaldhar H. Vyas)
Date: Sun Mar 23 10:27:02 2008
Subject: [cgiapp] RFC: Module::Starter::Plugin::CGIApp
Message-ID: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>

I've been playing with Module::Starter recently and I wrote a plugin which 
creates a basic CGI::Application based module.  It should be wending its 
way to CPAN as we speak.

What do you think?  I would appreciate any comments, bug reports or 
patches.  In particular I am interested in implementing as many "best 
practices" as possible.

-- 
Jaldhar H. Vyas <jaldhar@braincells.com>
From ron at savage.net.au  Sun Mar 23 18:51:14 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Mar 23 18:47:23 2008
Subject: [cgiapp] RFC: Module::Starter::Plugin::CGIApp
In-Reply-To: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>
References: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>
Message-ID: <1206312674.6785.17.camel@zoe.savage.net.au>

Hi Jaldhar

On Sun, 2008-03-23 at 10:26 -0400, Jaldhar H. Vyas wrote:
> I've been playing with Module::Starter recently and I wrote a plugin which 
> creates a basic CGI::Application based module.  It should be wending its 
> way to CPAN as we speak.

It'd be easier to find if we knew its name...

> What do you think?  I would appreciate any comments, bug reports or 
> patches.  In particular I am interested in implementing as many "best 
> practices" as possible.

It needs to go further than just automatically writing code - it needs
to automatically debug it as well :-)).
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From jaldhar at braincells.com  Sun Mar 23 19:49:42 2008
From: jaldhar at braincells.com (Jaldhar H. Vyas)
Date: Sun Mar 23 19:49:53 2008
Subject: [cgiapp] RFC: Module::Starter::Plugin::CGIApp
In-Reply-To: <1206312674.6785.17.camel@zoe.savage.net.au>
References: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>
	<1206312674.6785.17.camel@zoe.savage.net.au>
Message-ID: <alpine.DEB.1.00.0803231947240.7604@jaldhar-laptop>

On Mon, 24 Mar 2008, Ron Savage wrote:

> It'd be easier to find if we knew its name...
>

Module::Starter::Plugin::CGIApp

as in the subject :-)

-- 
Jaldhar H. Vyas <jaldhar@braincells.com>
From ron at savage.net.au  Sun Mar 23 21:54:12 2008
From: ron at savage.net.au (Ron Savage)
Date: Sun Mar 23 21:50:29 2008
Subject: [cgiapp] RFC: Module::Starter::Plugin::CGIApp
In-Reply-To: <alpine.DEB.1.00.0803231947240.7604@jaldhar-laptop>
References: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>
	<1206312674.6785.17.camel@zoe.savage.net.au>
	<alpine.DEB.1.00.0803231947240.7604@jaldhar-laptop>
Message-ID: <1206323652.6785.22.camel@zoe.savage.net.au>

Hi Jaldhar

> > It'd be easier to find if we knew its name...
> >
> 
> Module::Starter::Plugin::CGIApp
> 
> as in the subject :-)

How sneaky is that!?

In this doc:
http://search.cpan.org/~jaldhar/Module-Starter-Plugin-CGIApp-0.01/lib/Module/Starter/Plugin/CGIApp.pm
I was confused by $data_item. What is it? I did search some other
modules you refer to, but didn't find any explanation.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html


From jaldhar at braincells.com  Sun Mar 23 22:30:32 2008
From: jaldhar at braincells.com (Jaldhar H. Vyas)
Date: Sun Mar 23 22:30:40 2008
Subject: [cgiapp] RFC: Module::Starter::Plugin::CGIApp
In-Reply-To: <1206323652.6785.22.camel@zoe.savage.net.au>
References: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>
	<1206312674.6785.17.camel@zoe.savage.net.au>
	<alpine.DEB.1.00.0803231947240.7604@jaldhar-laptop>
	<1206323652.6785.22.camel@zoe.savage.net.au>
Message-ID: <alpine.DEB.1.00.0803232220310.7604@jaldhar-laptop>

On Mon, 24 Mar 2008, Ron Savage wrote:

>
> In this doc:
> http://search.cpan.org/~jaldhar/Module-Starter-Plugin-CGIApp-0.01/lib/Module/Starter/Plugin/CGIApp.pm
> I was confused by $data_item. What is it? I did search some other
> modules you refer to, but didn't find any explanation.

I was wondering if I had I had explained that properly.  Basically the 
problem is that HTML::Template wants lists of hashes for tmpl_loops.  So 
if you have  $data = ['a', 'b', 'c'];  it would get converted to

$data = [
    { data_item => 'a' },
    { data_item => 'b' },
    { data_item => 'c' },
];

so that in the template you could say

<tmpl_loop data>
     <tmpl_var data_item>
</tmpl_loop>

In retrospect I should have used foo or something instead of data to 
indicate it is just an example.

-- 
Jaldhar H. Vyas <jaldhar@braincells.com>
From perl.cgiapp at rjbs.manxome.org  Mon Mar 24 10:31:18 2008
From: perl.cgiapp at rjbs.manxome.org (Ricardo SIGNES)
Date: Mon Mar 24 10:31:23 2008
Subject: [cgiapp] RFC: Module::Starter::Plugin::CGIApp
In-Reply-To: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>
References: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>
Message-ID: <20080324143118.GA20927@70-8-165-36.area4.spcsdns.net>

* "Jaldhar H. Vyas" <jaldhar@braincells.com> [2008-03-23T10:26:31]
> I've been playing with Module::Starter recently and I wrote a plugin which 
> creates a basic CGI::Application based module.  It should be wending its 
> way to CPAN as we speak.

Cool.  Is there a reason it had to be a plugin and not just a set of templates?
Were it just a ModuleStore set of templates, it could be made easier to pick
what templates to use when creating a new dist...

But cool!

-- 
rjbs
From jaldhar at braincells.com  Tue Mar 25 14:28:20 2008
From: jaldhar at braincells.com (Jaldhar H. Vyas)
Date: Tue Mar 25 14:28:38 2008
Subject: [cgiapp] RFC: Module::Starter::Plugin::CGIApp
In-Reply-To: <20080324143118.GA20927@70-8-165-36.area4.spcsdns.net>
References: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>
	<20080324143118.GA20927@70-8-165-36.area4.spcsdns.net>
Message-ID: <alpine.DEB.1.00.0803251419440.10540@jaldhar-laptop>

On Mon, 24 Mar 2008, Ricardo SIGNES wrote:

>
> Cool.  Is there a reason it had to be a plugin and not just a set of templates?
> Were it just a ModuleStore set of templates, it could be made easier to pick
> what templates to use when creating a new dist...
>

Module::Starter is not as extensible as it could be.  I filed one bug 
about it already.  I was going to wait till I could offer some kind of 
patch before filing more.  I would also like to see the ability to add 
options to the module-starter command line application.

But it is possible I haven't fully understood how to go about extending so 
if you have suggestions, I'd like to hear them.

-- 
Jaldhar H. Vyas <jaldhar@braincells.com>
From perl.cgiapp at rjbs.manxome.org  Tue Mar 25 20:07:58 2008
From: perl.cgiapp at rjbs.manxome.org (Ricardo SIGNES)
Date: Tue Mar 25 20:08:10 2008
Subject: [cgiapp] RFC: Module::Starter::Plugin::CGIApp
In-Reply-To: <alpine.DEB.1.00.0803251419440.10540@jaldhar-laptop>
References: <alpine.DEB.1.00.0803231025390.7604@jaldhar-laptop>
	<20080324143118.GA20927@70-8-165-36.area4.spcsdns.net>
	<alpine.DEB.1.00.0803251419440.10540@jaldhar-laptop>
Message-ID: <20080326000758.GA30496@knight.local>

* "Jaldhar H. Vyas" <jaldhar@braincells.com> [2008-03-25T14:28:20]
> Module::Starter is not as extensible as it could be.

So true! :(

> I filed one bug about it already.  I was going to wait till I could offer
> some kind of patch before filing more.  I would also like to see the ability
> to add options to the module-starter command line application.

I'd like for module-starter to use App::Cmd.  I don't have many tuits lately,
though.

> But it is possible I haven't fully understood how to go about extending so 
> if you have suggestions, I'd like to hear them.

For simple things like "make a dist with different templates" the only thing
that needs to change should be the template store.  You want to say, "Instead
of using my normal templates, use the ones HERE."

Making that possible should be easy, probably with --opt templates=STORE or
something being added.

-- 
rjbs
From ron at savage.net.au  Thu Mar 27 19:47:47 2008
From: ron at savage.net.au (Ron Savage)
Date: Thu Mar 27 19:43:48 2008
Subject: [cgiapp] Test Failures with CGI::Application::Plugin::TT
In-Reply-To: <fd8e28ef0803091736o670c8278l404b31a072aca79f@mail.gmail.com>
References: <47CD6D2D.29220.12810A9@lackhoff.zbmed.uni-koeln.de>
	<fd8e28ef0803091736o670c8278l404b31a072aca79f@mail.gmail.com>
Message-ID: <1206661667.6785.118.camel@zoe.savage.net.au>

Hi Cees

Is this V 1.04 of CGI::Application::Plugin::TT?

I just re-ran the tests and (shock, horror :-) they all worked:

ron@zoe:~/perl.modules/CGI-Application-Plugin-TT-1.04$ perl Build test
t/01_basic...............ok   
t/02_error...............ok   
t/03_tname...............ok     
t/04_singleton...........ok   
t/05_include_path........ok   
t/06_callback............ok   
t/07_devpopup............skipped: CGI::Application::Plugin::DevPopup
required for these tests
t/08_load_tmpl...........ok   
t/09_precompile_dir......ok   
t/98_pod.................ok   
t/99_pod_coverage........ok   
All tests successful.
Files=11, Tests=60,  2 wallclock secs ( 0.10 usr  0.03 sys +  1.71 cusr
0.24 csys =  2.08 CPU)
Result: PASS

Anything changed that you know of?

I'm using Template::Provider with the original line 213:
$path = "$dir/$name";
since it may that he stores all template info with Unix paths in the
cache. Nevertheless, I've logged a ticket with RT: 34489.
-- 
Ron Savage
ron@savage.net.au
http://savage.net.au/index.html