Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so now
one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm
going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one list of the other?
-=Chris
Re: [PATCH] Test TestRequest pod
Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) Another opinion question amungst the A-TR and t/modperl changes: module2url vs. module2uri and my $url =vs. my $uri = -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) Another opinion question amungst the A-TR and t/modperl changes: module2url vs. module2uri and my $url =vs. my $uri = Frankly I can never tell the difference (I know there is one). I normally use url... but whatever you like -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? If you use a relative path, it just goes to the default http://localhost:8529/. Not madness but for the sake of simplicity. Use relative path, unless you want to talk to a different port. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. Baby steps, Chris. Baby steps. I should have a set of patches out for modperl/t and A::TR::module2url shortly after a few more distclean/nmake tests. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Baby steps, Chris. Baby steps. :) I should have a set of patches out for modperl/t and A::TR::module2url shortly after a few more distclean/nmake tests. chris++ -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Now I have to go searching again. :-) modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. I know there's a couple more lurkers in there, but maybe I'll stumble across those during another round of module2path-ing. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Now I have to go searching again. :-) modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. You mean t/hooks/trans.t? sure it does: Apache::TestRequest::module($module); or are you talking about a different test? I know there's a couple more lurkers in there, but maybe I'll stumble across those during another round of module2path-ing. -=Chris -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. You mean t/hooks/trans.t? sure it does: Apache::TestRequest::module($module); or are you talking about a different test? ANd so it does. On that note, I'm going to bed. :-/
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: Stas Bekman wrote: Still someone needs to do the work and verify that things are working. That will fun in and of itself. Right now, the only thing close to meeting the requirements of running the overall tests is my 5.6.1 install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03. It'll probably take some time just to get my unmodded working copy to run all of it's test before I even start coding. I may just have to whip up another FBSD tinker box. -=Chris And so it starts. I'm having problems subscribing to the modperl-win32 list at the moment, otherwise I'd ask this there. I had no idea such list exists. Is there any other way to test my changes other than trying to build mp2 itself? Probably not, since it relies on the fact that it has an access to the source. I want to get started on the changes but I can get mp2 to build on Win32: Configure mod_perl with C:\Development\Apache2? [y] Configuring Apache/2.0.52 mod_perl/1.99_18-dev Perl/v5.8.4 Note (probably harmless): No library found for /lib/libapr.lib Of course, my %LIB% contains the appropriate Apache2/lib directory and that dir is also in my Config.pm. Thanks for putting up with the newb. Please post this question to the modperl-dev list (with a relevant subject): http://perl.apache.org/maillist/dev.html and Randy will be able to help you. (I'm of no help on win32) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[PATCH] Test TestRequest pod
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional headers
via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \ and . The bare versions seemed to be the
most prevelant.
-=Chris
Index: Test.pm
===
--- Test.pm (revision 109410)
+++ Test.pm (working copy)
@@ -604,7 +604,7 @@
the tests will be skipped if the function returns a false value. For
example:
-plan tests = 5, \need_lwp;
+plan tests = 5, need_lwp;
the test will be skipped if LWP is not available
@@ -654,13 +654,13 @@
=item need_http11
- plan tests = 5, need_http11;
+ plan tests = 5, need_http11;
Require HTTP/1.1 support.
=item need_ssl
- plan tests = 5, need_ssl;
+ plan tests = 5, need_ssl;
Require SSL support.
@@ -668,13 +668,13 @@
=item need_lwp
- plan tests = 5, need_lwp;
+ plan tests = 5, need_lwp;
Require LWP support.
=item need_cgi
- plan tests = 5, need_cgi;
+ plan tests = 5, need_cgi;
Requires mod_cgi or mod_cgid to be installed.
Index: TestRequest.pm
===
--- TestRequest.pm (revision 109410)
+++ TestRequest.pm (working copy)
@@ -780,6 +780,19 @@
installed. It's best, therefore, to check Chave_lwp before running
tests that rely on a redirection from CPOST.
+Sometimes it is desireable to have CApache::TestRequest remember
+cookies sent by the pages you are testing and send them back to the
+server on subsequent requests. This is especially necessary when
+testing pages whose functionality relies on sessions or the presence
+of preferences stored in cookies.
+
+By default, CLWP::UserAgent does Bnot remember cookies between
+requests. You can tell it to remember cookies by adding the following
+to Cuser_agent():
+
+ Apache::TestRequest::user_agent(reset =,
+ cookie_jar = {});
+
=head1 FUNCTIONS
CApache::TestRequest exports a number of functions that will likely
@@ -837,6 +850,11 @@
Sends a simple GET request to the Apache test server. Returns an
CHTTP::Response object.
+You can also supply additional headers to be sent with the request
+by adding their name/value pairs after the Curl parameter:
+
+ my $res = GET $url, 'Accept-Language' = 'de,en-us,en;q=0.5';
+
=head3 GET_STR
A shortcut function for CGET($uri)-Egtas_string.
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional headers
via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \ and . The bare versions seemed to be the
most prevelant.
Thanks Chris, commited. But see below.
Also in the future please try to post diffs against the root of the
project so it's easier to apply those. Thanks.
Index: TestRequest.pm
+ Apache::TestRequest::user_agent(reset =,
+ cookie_jar = {});
Sorry, but what's that 'reset = ' thing? I've committed just:
Apache::TestRequest::user_agent(cookie_jar = {});
as in the test.
=head1 FUNCTIONS
CApache::TestRequest exports a number of functions that will likely
@@ -837,6 +850,11 @@
Sends a simple GET request to the Apache test server. Returns an
CHTTP::Response object.
+You can also supply additional headers to be sent with the request
+by adding their name/value pairs after the Curl parameter:
really it's a dup of the more extensive docs at:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
but committed anyway :)
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional
headers via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \ and . The bare versions seemed to be
the most prevelant.
Thanks Chris, commited. But see below.
Also in the future please try to post diffs against the root of the
project so it's easier to apply those. Thanks.
I assume you mean http://svn.apache.org/repos/asf/httpd/test/trunk/, and
not just the root of Apache-Test correct?
No, no, the root of A-T. An example will be more useful:
--- lib/Apache/Test.pm (revision 109410)
+++ lib/Apache/Test.pm (working copy)
I can chdir into the root of the project and apply your patch immediately.
Index: TestRequest.pm
+ Apache::TestRequest::user_agent(reset =,
+ cookie_jar = {});
Sorry, but what's that 'reset = ' thing? I've committed just:
Apache::TestRequest::user_agent(cookie_jar = {});
as in the test.
Geez. Apparently I'm in the clouds this week. Maybe I need to do these
changes during the day instead of at night. :-/
:)
=head1 FUNCTIONS
CApache::TestRequest exports a number of functions that will likely
@@ -837,6 +850,11 @@
Sends a simple GET request to the Apache test server. Returns an
CHTTP::Response object.
+You can also supply additional headers to be sent with the request
+by adding their name/value pairs after the Curl parameter:
really it's a dup of the more extensive docs at:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
Well, yes, and that was on purpose. I hated reading the A-T pod and
never knowing there was an extra param for GET. THe pod usualy is enough
to get start, and I wouldn't exptec to have to read:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
Agreed, but dups are evil from the maintenance point of view. I'd rather
have everything in one place and have the other document link to the first
one. Unfortunately A-T pods are nowhere on perl.apache.org.
Were you looking for something more extensive?
No, no, it's perfectly fine. The next person looking for the same solution
will most likely easily find it.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: No, no, the root of A-T. An example will be more useful: --- lib/Apache/Test.pm(revision 109410) +++ lib/Apache/Test.pm(working copy) I can chdir into the root of the project and apply your patch immediately. Understood. Makes sense. Agreed, but dups are evil from the maintenance point of view. I'd rather have everything in one place and have the other document link to the first one. Unfortunately A-T pods are nowhere on perl.apache.org. Were you looking for something more extensive? No, no, it's perfectly fine. The next person looking for the same solution will most likely easily find it. On that note, what else can I work on? Apparently I'm a glutton for punishment. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so now
one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to
do for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so
now one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
Hmmm, sounds easy enough since you already included module2url. :-)
Famous last words.
Still someone needs to do the work and verify that things are working.
Is this just a concern in t/modperl? I came up with 77 hits in t/, and
11 of those are in t/modperl. Maybe that small subset is a same place
for me to start.
It's all t/. But you can start with a subset.
Am I correct in assuming that the modperl in SVN is the 2.0 trunk (the
one I want) and that 1.0 is stuck back in CVS? I'm still trying to wrap
my brainpan around what modules are where and what perl-framework really
encompasses.
That's correct. I tried to argue that we want it to be called modperl-2.0,
but the httpd-way was preferrable on other developers.
The online docs have all the info:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: Still someone needs to do the work and verify that things are working. That will fun in and of itself. Right now, the only thing close to meeting the requirements of running the overall tests is my 5.6.1 install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03. It'll probably take some time just to get my unmodded working copy to run all of it's test before I even start coding. I may just have to whip up another FBSD tinker box. -=Chris
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote:
I think all kind of refactoring would be great. One thing I wanted to
do for tests again vhosts, is to add this function next to
module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so
now one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
After another look at things like t/merge.t, it looks like there are at
least 2 different use cases for module2perl.
1) The $module sent to module2perl will be sent to ::module() and will
be the same as the path. This is your first example:
Foo::Bar = /Foo__Bar
2) The $module sent to module2perl will be sent to ::module(), but a
DIFFERENT path is required; like in merge3.t where the path ==
'/merge3/ != TestModperl::merge
What about make mopdeul2url have a hashref as the second arg in which we
can override $path, and of course $scheme
Apache::TestRequest::module2path('TestModePerl::merge', {
scheme = 'https',
path = '/merge3/
}
Of course it should take the necessary precautions for when / is and
isn't included, etc.
-=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
I think all kind of refactoring would be great. One thing I wanted
to do for tests again vhosts, is to add this function next to
module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so
now one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
After another look at things like t/merge.t, it looks like there are at
least 2 different use cases for module2perl.
1) The $module sent to module2perl will be sent to ::module() and will
be the same as the path. This is your first example:
Foo::Bar = /Foo__Bar
2) The $module sent to module2perl will be sent to ::module(), but a
DIFFERENT path is required; like in merge3.t where the path ==
'/merge3/ != TestModperl::merge
What about make mopdeul2url have a hashref as the second arg in which we
can override $path, and of course $scheme
Apache::TestRequest::module2path('TestModePerl::merge', {
scheme = 'https',
path = '/merge3/
}
Isn't merge3 an odd ball? Originally I was thinking to do the refactoring
for the code which identical and leave the more complex cases alone. But
if you wish to implement the suggested functionality go for it. It
definitely makes the test more readable, and those wishing to use the old
functionality still can do that.
though it's module2url, not module2path (saw your update)
Of course it should take the necessary precautions for when / is and
isn't included, etc.
What do you mean? Examples?
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote:
Of course it should take the necessary precautions for when / is and
isn't included, etc.
What do you mean? Examples?
Well, let's go with the running sample:
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
If looks as though module2path() returns the path starting with /.
If we override that with the path from the hashref module2url($url,
{path = 'mypath'}) we would end up with scheme://host:portmypath
instead of scheme://host:port/mypath.
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
Of course it should take the necessary precautions for when / is and
isn't included, etc.
What do you mean? Examples?
Well, let's go with the running sample:
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
If looks as though module2path() returns the path starting with /.
If we override that with the path from the hashref module2url($url,
{path = 'mypath'}) we would end up with scheme://host:portmypath
instead of scheme://host:port/mypath.
You are correct. Then yes, if the $path argument is provided by the user
strip the leading /.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Still someone needs to do the work and verify that things are working. That will fun in and of itself. Right now, the only thing close to meeting the requirements of running the overall tests is my 5.6.1 install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03. It'll probably take some time just to get my unmodded working copy to run all of it's test before I even start coding. I may just have to whip up another FBSD tinker box. -=Chris And so it starts. I'm having problems subscribing to the modperl-win32 list at the moment, otherwise I'd ask this there. Is there any other way to test my changes other than trying to build mp2 itself? I want to get started on the changes but I can get mp2 to build on Win32: Configure mod_perl with C:\Development\Apache2? [y] Configuring Apache/2.0.52 mod_perl/1.99_18-dev Perl/v5.8.4 Note (probably harmless): No library found for /lib/libapr.lib Of course, my %LIB% contains the appropriate Apache2/lib directory and that dir is also in my Config.pm. Thanks for putting up with the newb. -=Chris
