Michael Peters (mp...@plusthree.com)

Will Fould wrote:

> I thought that packages loaded from different locations, (but with the
> same name), would not conflict.  Silly me.

This is because even though you've told apache to map a certain URL to a certain
script, there is only 1 running Perl interpreter. And since Perl only allows 1
file to occupy a certain namespace you get those conflicts.

> Is there a better way to do what I'm trying to do without running
> separate servers for each host?

The only way to have 2 different packages use the same package name is to have
separate Perls with different @INCS running. There's no way to do this under
Apache/mod_perl (that I'm aware of). So either run 2 different Apaches, or put
the modules into their own namespaces. Instead of "package Foo" do "package
ClientA::Foo".

The uploaded file

    CGI-Application-Plugin-JSON-0.2.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/W/WO/WONKO/CGI-Application-Plugin-JSON-0.2.tar.gz
  size: 4567 bytes
   md5: 2520e065600a002b3c1d370d91cc3d9c


NAME
    CGI::Application::Plugin::JSON - easy manipulation of JSON headers

SYNOPSIS
        use CGI::Application::Plugin::JSON ':all';

        # add_json_header() is cumulative
        $self->add_json_header( foo => 'Lorem ipsum...');
        $self->add_json_header( bar => [ 0, 2, 3, 4 ] );
$self->add_json_header( baz => { stuff => 1, more_stuff => 2 } );

        # json_header() is not cumulative
        $self->json_header( foo => 'Lorem ipsum...');

        # in case we're printing our own headers
        print "X-JSON: " . $self->json_header_string();

        # clear out everything in the outgoing JSON headers
        $self->clear_json_header();

        # or send the JSON in the document body
$self->json_body( { foo => 'Lorem ipsum', bar => [ 0, 2, 3 ] } );

DESCRIPTION
    When communicating with client-side JavaScript, it is common to send
    data in "X-JSON" HTTP headers or through the document body as
    content-type "text/x-json".

    This plugin adds a couple of convenience methods to make that just a
    little bit easier.

Doesn't look OK to me...

> URI.pm location: /usr/lib/perl5/Apache2/URI.pm
> Can't locate object method "new" via package "URI" at [blah]

That's Apache2::URI, not URI. What does the command line version of that same
script print? Do you have "/usr/lib/perl5/Apache2" in your @INC? If so, you
shouldn't (I believe that was an old 1.99 thing before the change into the
Apache2 namespace).

Kjetil Kjernsmo wrote:

> The first suspicion is of course that there exists a different package
> URI somewhere in the system, which is only used by the web server, but
> I can't find anything.

Print out $INC{'URI.pm'} from both Apache and the cmd line just to be sure
they're using the same thing.

I usually use Test::Class and Test::More, but that's my preference.

> 3.1)testing package method functionality separately from the ui
> 3.2)testing web interface of the entire application with LWP::UserAgent and
> XML::XPath

Again, I use WWW::Mechanize, Test::WWW::Mechanize and maybe Test::HTML::Content

> The thing is:I'd like to discuss the issues that might arise as the
> development goes on further with this way of working. As for now, I am happy
> with what I am doing, it feels quite good and correct:but=>if anyone has
> experience working this way I'd like to know what you/they have experienced.

One of the main irritants in testing the UI of a web application is that it can
change quite frequently. Now changing your tests when the program changes is to
be somewhat expected, but depending on the changes, it can get annoying. I would
recommend against testing for a specific structure and just testing for the
data. But hopefully most of the markup is abstracted enough that most UI changes
are done in the style sheets. Even with this irritant, these kind of tests have
caught many bugs for me that straight unit-testing would not have found.