On 2/28/2012 2:33 PM, Rhesa Rozendaal wrote:
On 02/28/2012 05:45 PM, Kurt Lidl wrote:
Greetings.
I've got a large application that is running under mod_perl, running on
Apache 2.2.22.
Everything is working OK there. It uses CGI::Application::Dispatch as
its invocation
method.
I'm using
On 2/28/2012 11:45 AM, Kurt Lidl wrote:
Greetings.
I've got a large application that is running under mod_perl, running on
Apache 2.2.22.
Everything is working OK there. It uses CGI::Application::Dispatch as
its invocation
method.
Debugging this further, I see that the PATH_INFO
On 02/28/2012 05:45 PM, Kurt Lidl wrote:
Greetings.
I've got a large application that is running under mod_perl, running on
Apache 2.2.22.
Everything is working OK there. It uses CGI::Application::Dispatch as
its invocation
method.
I'm using roughly the same stack, though I use starman in
On 03/11/2011 11:20 PM, Ron Savage wrote:
Hi James
On Fri, 2011-03-11 at 19:58 -0800, James.Q.L wrote:
Thanks for reporting it on RT.
I think C::A::D should respect C::A's start_mode. If no rm is defined in
C::A::D rules, the start_mode in the dispatched module should be used.
A
Hi James
I've logged an error report:
https://rt.cpan.org/Ticket/Display.html?id=66558
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
# CGI::Application community mailing list
####
## To unsubscribe,
...@savage.net.au wrote:
From: Ron Savage r...@savage.net.au
Subject: Re: [cgiapp] cgi::application::dispatch doesn't handle start_mode
To: CGI Application cgiapp@lists.erlbaum.net
Date: Friday, March 11, 2011, 3:59 PM
Hi James
I've logged an error report:
https://rt.cpan.org/Ticket
Hi James
On Fri, 2011-03-11 at 19:58 -0800, James.Q.L wrote:
Thanks for reporting it on RT.
I think C::A::D should respect C::A's start_mode. If no rm is defined in
C::A::D rules, the start_mode in the dispatched module should be used.
A sentence of describing the use of start_mode in
--- On Sat, 3/5/11, Ron Savage r...@savage.net.au wrote:
From: Ron Savage r...@savage.net.au
Subject: Re: [cgiapp] cgi::application::dispatch doesn't handle start_mode
To: CGI Application cgiapp@lists.erlbaum.net
Date: Saturday, March 5, 2011, 6:40 PM
Hi James
On Sat, 2011-03-05 at 01:25
Hi James
On Thu, 2011-03-10 at 20:15 -0800, James.Q.L wrote:
--- On Sat, 3/5/11, Ron Savage r...@savage.net.au wrote:
From: Ron Savage r...@savage.net.au
Subject: Re: [cgiapp] cgi::application::dispatch doesn't handle start_mode
To: CGI Application cgiapp@lists.erlbaum.net
Date
Hi,
It seems that C::A::D always sets the runmode to $rm_HTTP_METHOD even when $rm
is not set, which produces a _HTTP_METHOD runmode. that' doesn't work when
start_mode is expected to be run. it is due to the following code in the sub
dispatch { } from CAD,
if( $auto_rest ) {
Hi James
On Sat, 2011-03-05 at 01:25 -0800, James.Q.L wrote:
Hi,
It seems that C::A::D always sets the runmode to $rm_HTTP_METHOD even when
$rm is not set, which produces a _HTTP_METHOD runmode. that' doesn't work
when start_mode is expected to be run. it is due to the following code in
Thanks! this looks like it will work perfectly.
However, I'm still having a bit of trouble getting dispatching to work
properly. I have a handler set up under mod_perl to send all requests
that start with /dispatchperl/ to my dispatcher, and I have verfiied
that this setup is infact handling
I'm trying to play around with CGI::Application::Dispatch a bit and I'm
having some trouble getting it working and I'm hoping someone who has
experience with this module can offer some advice.
I have subclassed CGI::Application::Dispatch as follows:
package MyDispatch;
use base
On 04/27/2010 03:12 PM, Brad Van Sickle wrote:
[Tue Apr 27 11:58:35 2010] -e: [Dispatch] ERROR for request
'/dispatchperl/': Can't locate object method new via package
public::Packages::PublicSite at
/usr/lib/perl5/site_perl/5.8.8/CGI/Application/Dispatch.pm line 702.
[Tue Apr 27 11:58:35
CGI::Application 2.16 was released last night. This release fixes some minor
bugs and improves the documentation. This release also completely cleared
out the bug queue for the distribution.
You can download it here:
http://search.cpan.org/~markstos/CGI-Application-Dispatch-2.16/
Thanks to all
On Wed, Feb 11, 2009 at 5:45 AM, Lyle webmas...@cosmicperl.com wrote:
Hi All,
I was just looking at this modules docs and I noticed it says:-
It will translate a URI like this (under mod_perl):
/app/module_name/run_mode
or this (vanilla cgi)
/app/index.cgi/module_name/run_mode
I'm
Hi All,
I was just looking at this modules docs and I noticed it says:-
It will translate a URI like this (under mod_perl):
/app/module_name/run_mode
or this (vanilla cgi)
/app/index.cgi/module_name/run_mode
I'm guess it might have come up before, but might be worth mentioning
Lyle wrote:
Which is way, way more SEO friendly.
Really? A .html extension makes it easier for Google (the only one that really matters
http://www.codinghorror.com/blog/archives/001224.html) to find it? What evidence do you have for that?
If someone knows the Apache config to get this
P Kishor wrote:
CGI::Application::Dispatch-dispatch(
prefix = '',
default = '',
debug = 1,
table = [
'' = { app = $App, rm = 'view' },
'find' = { app = $App, rm = 'find', },
'view/:p?/:o?/:s?' = { app = $App, rm =
fREW Schmidt wrote:
I am a little confused about how CAD is supposed to work I guess.
Let's see if we can help...
First off, I have a directory, call it abc.
That right there is kind of a red-flag. Not that you're doing anything wrong, but Apache has a weird
notion of PATH_INFO when a
That right there is kind of a red-flag. Not that you're doing anything wrong,
but Apache has a weird notion of PATH_INFO when a real directory exists. And
Dispatch relies on PATH_INFO for parsing. You can check what Apache thinks it
is by printing the $ENV{PATH_INFO} in your Dispatch.pm.
To save you all a bunch of frustration and time, please be aware of
the following subtle distinction between PATH_INFO on IIS and Apache:
Consider this URL: http://yourserver/myscript.pl/foo/bar
On Apache, PATH_INFO will be set to /foo/bar. On IIS, PATH_INFO is /
myscript.pl/foo/bar. This
Jason A. Crome wrote:
mpeters: If I sent you a CGI::Application::Dispatch::IIS subclass, could
you (or Mark) incorporate it into the CA::Dispatch distribution? Or, if
you don't want to mess with it and wouldn't mind another co-maintainer,
I'd be happy to maintain this bit of it.
I'd be
I just sent a new release of CGI::Application::Dispatch to CPAN.
Just a couple of logging improvements in this release:
- Logging improvement: Quit duplicating $ENV{REQUEST_URI} for Not Found
requests (Mark Stosberg)
- Logging improvement: Remove stray ' character (Mark Stosberg)
Mark
CGI::Application::Dispatch 2.14 has just been sent to CPAN. Changes since the
last stable release are as follows. Thanks to Bradley Baily for the new
dispatch_path() method as well as Puneet Kishor and others for the reporting a
make test problem.
2.14 Nov 2, 2008
- New feature:
For those of you having installation problems with CGI::Application::Dispatch,
version 2.13 has just been uploaded to CPAN to address them.
Thanks to the bug reporters and Michael Peters who are responsible for the
code updates in this release.
This new release is also the last blocker for
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
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
(that probably means something is mucked up with them :)
Good Luck,
Lee
- Original Message
From: Todd Ross [EMAIL PROTECTED]
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
Todd Ross wrote:
[EMAIL PROTECTED]:~/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
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,
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
Hello Michael,
[EMAIL PROTECTED]:~/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
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
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.
[EMAIL
On Fri, Mar 7, 2008 at 8:34 AM, Todd Ross [EMAIL PROTECTED] 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
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
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:
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
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
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
Hello
I'm using CGI::Application::Dispatch under mod_perl 2 to display all the pages
on a site I'm working on and have had problems getting it to play nicely with
path_info as reported by Apache.
What I would like to happen is:
Request: http://example.com/foo/bar
Calls: run mode bar in module
Simon Rees wrote:
Hello
I'm using CGI::Application::Dispatch under mod_perl 2 to display all the
pages
on a site I'm working on and have had problems getting it to play nicely with
path_info as reported by Apache.
What I would like to happen is:
Request: http://example.com/foo/bar
Alexander Becker wrote:
I thought on using prefix = '' in the dispatch specific configuration,
but that only for additional prefixes, it doesn't alter the global
prefix (and that makes sense).
Yeah, that's a bug in Dispatch. It should be able to work like that. Let me see
if I can fix that
Hello!
I use CGI::Application::Dispatch with a dispatch table. There, I specify
that all my modules are under a prefiy 'My'.
That works fine, as long as I write all modules my own. But today, I
wanted to use the CGI::Application::Photogallery. That didn't work because
the request was
Alexander Becker wrote:
Hi Alexander
That works fine, as long as I write all modules my own. But today, I
wanted to use the CGI::Application::Photogallery. That didn't work
One way would be to sub-class that module, with a My:: prefix.
Then, you could, perhaps, have that module know where
Hi Mike
On 6/13/07, Simon Rees [EMAIL PROTECTED] wrote:
Location /srees/connectm_tracker
SetHandler perl-script
PerlHandler CGI::Application::Dispatch
PerlSetVar CGIAPP_DISPATCH_PREFIX Newforms::MembersCGIApp::Dispatch
PerlSetVar CGIAPP_DISPATCH_DEFAULT /public/front
Hi
I'm using CGI::Application::Dispatch for the first time and am having some
trouble configuring it on a test server. Hopefully someone on this list who
is more skilled with this module can help me :-)
The custom for a url on our test server is:
http://test.server/username/project
However,
On 6/13/07, Simon Rees [EMAIL PROTECTED] wrote:
Location /srees/connectm_tracker
SetHandler perl-script
PerlHandler CGI::Application::Dispatch
PerlSetVar CGIAPP_DISPATCH_PREFIX Newforms::MembersCGIApp::Dispatch
PerlSetVar CGIAPP_DISPATCH_DEFAULT /public/front
PerlSetVar
Dan Horne wrote:
From: Michael Peters
Then grab the latest dev version from CPAN - 2.10_02
(uploaded about 10 minutes
ago) which should only use Apache::Test if you already have
it installed and won't list it as a pre-req. It will also
skip the mod_perl tests as well.
Hi Michael
Michael Peters wrote:
Dan Horne wrote:
Just a side note - I
initially attempted to run Makefile.PL (out of habit, I guess) and it failed
due to the Apache::Test dependency. However, Build.PL worked fine and dandy
Thanks for the catch. I've fixed this too and the final release is on
From: Michael Peters
Then grab the latest dev version from CPAN - 2.10_02
(uploaded about 10 minutes
ago) which should only use Apache::Test if you already have
it installed and won't list it as a pre-req. It will also
skip the mod_perl tests as well.
Hi Michael
Thanks for your help
Hi
I currently use CGI::Application::Dispatch v1 with FastCGI, and it works
very well for me. I'd like to start using v2 in order to take advantage of
the URL matching capability, but understand that there are URL caching
problems
Dan Horne wrote:
Hi
I currently use CGI::Application::Dispatch v1 with FastCGI, and it works
very well for me. I'd like to start using v2 in order to take advantage of
the URL matching capability, but understand that there are URL caching
problems
-Original Message-
From: Michael Peters
Sent: Friday, 12 January 2007 7:02 a.m.
I've received feedback from 1 other FCGI user who said it
solved his problem. Please try it out. The interface won't
change between the dev release the next public release, so
even if something
Dan Horne wrote:
I received the following message when running the tests:
[ error] You are using mod_perl response handlers
[ error] but do not have a mod_perl capable Apache.
Someone in #cgiapp just reported the same thing. It works fine for me so I'm not
sure of the exact issue. I did
From: Michael Peters
Dan Horne wrote:
I received the following message when running the tests:
[ error] You are using mod_perl response handlers [ error] but do
not have a mod_perl capable Apache.
Someone in #cgiapp just reported the same thing. It works
fine for me so I'm not
Dan Horne wrote:
From: Michael Peters
Dan Horne wrote:
I received the following message when running the tests:
[ error] You are using mod_perl response handlers [ error] but do
not have a mod_perl capable Apache.
Someone in #cgiapp just reported the same thing. It works
fine for me
From: Michael Peters
... grab the latest dev version from CPAN - 2.10_02
(uploaded about 10 minutes
ago) which should only use Apache::Test if you already have
it installed and won't list it as a pre-req. It will also
skip the mod_perl tests as well.
Thanks Michael
I'll let you know
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm setting up a new application and finally using version 2.x of
CGI::Application::Dispatch. My dispatch table so far looks like this:
table = [
':instance/app' = { app = 'Welcome', rm = 'welcome' },
Shawn Sorichetti wrote:
I'm setting up a new application and finally using version 2.x of
CGI::Application::Dispatch. My dispatch table so far looks like this:
table = [
':instance/app' = { app = 'Welcome', rm = 'welcome' },
':instance/app/module/:rm/:object' = { app = 'Module' },
David Steinbrunner wrote:
In an effort to figure out more about the reasoning of the caching I started
looking over the docs more and found the PROTECTED METHODS section that
talks about the _get_cache and _set_cache methods. At that point I had the
bright idea of sub classing them so that
From: David Steinbrunner On Behalf Of
David Steinbrunner
Sent: Saturday, 18 November 2006 11:54 a.m.
Subject: [cgiapp] CGI::Application::Dispatch and FastCGI
Hello all,
Has any one before me Mixed Dispatch and FastCGI?
It seems that the query object is getting cached. To elaborate
Dan Horne wrote:
Hmm, I had a similar problem while back, where previous GET and POST data
would seem to reappear. Upgrading CGI (and hence CGI::Fast) made it go away
for me...
The box I'm using was built recently and I made sure to update used modules,
so that should not be an issue. Here
From: David Steinbrunner
Dan Horne wrote:
Hmm, I had a similar problem while back, where previous GET
and POST
data would seem to reappear. Upgrading CGI (and hence
CGI::Fast) made
it go away for me...
The box I'm using was built recently and I made sure to
update used
Hello all,
Has any one before me Mixed Dispatch and FastCGI?
It seems that the query object is getting cached. To elaborate, I can start
up the web server, submit a form and it works but using that same form any
number of times after that ends up using the values from the first submit.
If I use
Hello folks,
Has anyone else had problems using CGI::Carp's 'fatalsToBrowser'
along with CGI::Application::Dispatch?
Dispatch wraps the CGI::Application run in an eval. When an
exception is caught, the http_error() method is called, which
generates HTML output for an error page (and redirects
Ron Savage wrote:
Hi Michael
The Synopsis has a sub called args_to_dispatch but it should be dispatch_args.
Thanks for catching that. It's fixed and will be in the next release (2.00)
--
Michael Peters
Developer
Plus Three, LP
Hi Michael
META.yml needs a few lines re requirements. Here's a hint (from cgi.t and
handler.t):
use Test::More;
use Test::LongString max = 500;
use IO::Scalar;
use Apache::Test qw(have_lwp need_module :withtestmore);
use Apache::TestRequest qw(GET);
use Apache::TestUtil qw(t_cmp);
use
Hi Michael
The Synopsis has a sub called args_to_dispatch but it should be dispatch_args.
--
Ron Savage
[EMAIL PROTECTED]
http://savage.net.au/index.html
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
Hi Michael
I installed V 1.04 without error. Then I installed Test::LongString. Then...
(1) Command: perl Build test
Output:
lib\CGI\Application\Dispatch.pm - blib\lib\CGI\Application\Dispatch.pm
d:\Perl\bin\perl.exe -I
D:\perl-modules\CGI-Application-Dispatch-2.00_03\blib\lib -I
From: Michael Peters
Sent: Friday, 4 November 2005 2:47 a.m.
I have never used Persistent Perl so I won't be much help there, but
here are some general suggestions:
+ Do you know where it's hanging? Try putting in lots of debug stuff
to see if it's actually hanging in C::A::D or in some
Dan Horne wrote:
Hi
I'm not sure if this is the correct place to raise this issue, but since
some on the list use C::A and Persistent Perl, maybe they can help (the PP
list seems dead).
My problem is that over time, my instance script hangs when it uses
Persistent Perl - it may take a
Hi
I'm not sure if this is the correct place to raise this issue, but since
some on the list use C::A and Persistent Perl, maybe they can help (the PP
list seems dead).
My problem is that over time, my instance script hangs when it uses
Persistent Perl - it may take a couple of hours before
Hi Michael.
So, if I understand you correctly, there are 2 reasons for this module.
1 - When you use C::A::Dispatch you can have links that actually go to a
module/run_mode without explicitly specifying them because you can set
the default in the application. And these links don't look like
Kensuke Kaneko wrote:
Hello, everyone!
I made a module named CGI::Application::Dispatch::BuildURI.
This module resolve a relative URI path's problem when writing template
files.
When I use CGI::Application::Dispatch, I often confused by relative
URI path difference.
For example,
Hello, everyone!
I made a module named CGI::Application::Dispatch::BuildURI.
This module resolve a relative URI path's problem when writing template files.
When I use CGI::Application::Dispatch, I often confused by relative
URI path difference.
For example, following two URI call same module
Hi Folks
Thanx for the responses.
Actually, I use registry scripts, but yes, the code will run under mod_perl, but
not as a native mod_perl handler.
Also, there was a problem with the version of Apache::Test, as discussed on the
mod_perl mailing list a few weeks ago, to do with Randy Kobes'
On Fri, Mar 11, 2005 at 09:24:27AM -0500, Michael Peters wrote:
It seems like Apache::Test is not working on your installation. Looking
at the output from the test and you error log, it does not appear that
it even reaches the C::A::Dispatch portions of the test.
FWIW, I've been using A::T
Ron Savage wrote:
Hi Michael
This gets into an infinite loop:
-8-
F:\perl-modules\CGI-Application-Dispatch-1.03perl Build test
f:\Perl\bin\perl.exe -I F:\perl-modules\CGI-Application-Dispatch-1.03\blib\lib
-I F:\perl-modules\CG
I-Application-Dispatch-1.03\blib\arch t\TEST -clean
80 matches
Mail list logo
