You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by Philip Mak <pm...@aaanime.net> on 2001/06/14 01:06:55 UTC
Object Oriented Databases with MySQL
Hello all,
I've been experimenting with a programming technique idea I had that I
call "Object Oriented Databases". The goal of the technique is to make
programming database driven websites easier by allowing the website code
(I use Apache::ASP, which is built on mod_perl) to access the database
contents as objects rather than having to write SQL statements. (The SQL
statements are in the .pm files that define the objects' methods.)
I'm using this technique to develop shoujoai.com, a site that hosts
stories written by various online authors. There is a table called
"authors" that has fields such as "name" and "email". There is a table
called "fanfics" containing the stories, which is linked to the "authors"
table by the "aid" (author id number) field.
In perl/MySQL, if I wanted to list all the stories, along with their
authors, I would have to do something like:
my $sth = query("SELECT * FROM fanfics, authors
WHERE fanfics.aid = authors.aid
ORDER BY fanfics.title");
while (my $row = $sth->fetchrow_hashref) {
print "<a href=\".$row->{handle}.".html\">".$row->{title}."</a> by".
"<a href=\"mailto:".$row->{email}."\">".
$row->{name}."</a><br>\n";
}
In an object oriented style, I would do:
use Fanfics;
my @fanfics = Fanfics::loadall();
for my $fanfic (@fanfics) {
print "<a href=\".$fanfic->handle.".html\">".$fanfic->title."</a> by".
"<a href=\"mailto:".$fanfic->author->email."\">".
$fanfic->author->name."</a><br>\n";
}
In the object oriented version, the resulting code is simpler (I don't
have to write MySQL statements in there). This simple example doesn't show
the full potential of this technique, because all the fields in the
database are simple ones - I don't have to combine data from multiple rows
in order to get a single piece of information about an entity.
Fanfic.pm would look something like this:
sub loadall {
my $sth = query("SELECT * FROM fanfics ORDER BY title");
my @fanfics;
while (my $row = $sth->fetchrow_hashref) {
push(@fanfics, bless($row));
}
return @fanfics;
}
sub title {
my $self = shift;
if (@_) { $self->{title} = shift }
return Apache::Util::escape_html($self->{title});
}
sub author {
my $self = shift;
return Author::loadaid($self->{aid});
}
One of the early problems I'm running into with this style of programming
is that the flexibility of the MySQL queries is somewhat limited. In a
database driven website where the relationships between the database
tables/entities are well defined and known in advance, ad hoc queries are
probably not needed so that the design of the *.pm files can account for
every possible query that may need to be executed.
Has anyone ever done anything like this before? Do you have any comments
about this technique?
Thanks,
-Philip Mak (pmak@aaanime.net)
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Object Oriented Databases with MySQL
Posted by Michael A Mayo <mi...@worldnet.att.net>.
----- Original Message -----
From: "Philip Mak" <pm...@aaanime.net>
To: <db...@perl.org>
> I've been experimenting with a programming technique idea I had that I
> call "Object Oriented Databases". The goal of the technique is to make
> programming database driven websites easier by allowing the website code
> (I use Apache::ASP, which is built on mod_perl) to access the database
> contents as objects rather than having to write SQL statements. (The SQL
> statements are in the .pm files that define the objects' methods.)
OODBMS is not a new idea; they have been around for a long time. You might
want to take a look at comp.object or comp.databases.object. However, many
people still want to use an RDBMS for storage for various reasons, but use
OO programming techniques and pretend they are dealing with an OODBMS. So,
they construct an OO<-->RDBMS mapping layer that looks like an interface to
an OODBMS, but translates that to RDBMS commands.
In another language, you might have to pay big $$ for an RDBMS<->OO mapping
layer. In Perl, however, we are lucky to have the excellent and free
Tangram. It does pretty much everything you would want an OO<-->RDBMS
mapping layer to do, except for support for changes in the object model.
You don't even have to inherit all your persistant classes from a base class
or any other similar magic.
Take a look at the Guided Tour: www.tangram-persistence.org
> One of the early problems I'm running into with this style of programming
> is that the flexibility of the MySQL queries is somewhat limited. In a
> database driven website where the relationships between the database
> tables/entities are well defined and known in advance, ad hoc queries are
> probably not needed so that the design of the *.pm files can account for
> every possible query that may need to be executed.
Building an OO::RDBMS mapping layer is a little complicated, and you are not
doing it correctly.
What you want to do is this:
* Make your object model normally, without any thought to the DBMS, so that
it is not depenant on the DBMS
* For each class, make a separate DB interface class that deals with storing
and retriving objects of that class. Make a main DB class that deals with
connecting to the database and other DB-related things.
* If you have lots of associations, it gets more complicated. You may just
want to put the association-related stuff in the main DB class, or put the
association stuff in each class that has the association, or make separate
association classes and make a DB interface for each association class.
For example, you might have something like this:
package Airplane;
sub takeoff {}
sub land {}
sub change_destination {}
package DB;
sub connect { #this would be constructor }
sub disconnect {}
sub start_transaction {}
sub finish_transaction {}
package DB::Airplane
sub insert {}
sub delete {}
sub getByAltitude {}
sub getBySpeed {}
sub getByDestination {}
sub getByAny {}
Dealing with associations and inheritance is complicated and annoying, but
can be done. If you want to roll your own, I suggest you do a search on
google for OO RDBMS mapping layer, or ask some questions in comp.object.
However, it is much easier to just use Tangram; all that suff is already
done for you. =)
> Has anyone ever done anything like this before? Do you have any comments
> about this technique?
I have been using Tangram and Template-Toolkit to develop a webapp, so far,
so good. =) The main problem is that it is a pain the the butt to have to
remake the Tangram "schema" (object model) every time I do any significant
refactoring.
-Mike
--caemblchncchjijjfifc--
ReSent-Date: Fri, 29 Jun 2001 14:50:44 -0700 (PDT)
ReSent-From: Ask Bjoern Hansen <as...@valueclick.com>
ReSent-To: <as...@perl.apache.org>
ReSent-Subject: Re: Object Oriented Databases with MySQL
ReSent-Message-ID: <Pi...@impatience.valueclick.com>
----- Original Message -----
From: "Philip Mak" <pm...@aaanime.net>
To: <db...@perl.org>
> I've been experimenting with a programming technique idea I had that I
> call "Object Oriented Databases". The goal of the technique is to make
> programming database driven websites easier by allowing the website code
> (I use Apache::ASP, which is built on mod_perl) to access the database
> contents as objects rather than having to write SQL statements. (The SQL
> statements are in the .pm files that define the objects' methods.)
OODBMS is not a new idea; they have been around for a long time. You might
want to take a look at comp.object or comp.databases.object. However, many
people still want to use an RDBMS for storage for various reasons, but use
OO programming techniques and pretend they are dealing with an OODBMS. So,
they construct an OO<-->RDBMS mapping layer that looks like an interface to
an OODBMS, but translates that to RDBMS commands.
In another language, you might have to pay big $$ for an RDBMS<->OO mapping
layer. In Perl, however, we are lucky to have the excellent and free
Tangram. It does pretty much everything you would want an OO<-->RDBMS
mapping layer to do, except for support for changes in the object model.
You don't even have to inherit all your persistant classes from a base class
or any other similar magic.
Take a look at the Guided Tour: www.tangram-persistence.org
> One of the early problems I'm running into with this style of programming
> is that the flexibility of the MySQL queries is somewhat limited. In a
> database driven website where the relationships between the database
> tables/entities are well defined and known in advance, ad hoc queries are
> probably not needed so that the design of the *.pm files can account for
> every possible query that may need to be executed.
Building an OO::RDBMS mapping layer is a little complicated, and you are not
doing it correctly.
What you want to do is this:
* Make your object model normally, without any thought to the DBMS, so that
it is not depenant on the DBMS
* For each class, make a separate DB interface class that deals with storing
and retriving objects of that class. Make a main DB class that deals with
connecting to the database and other DB-related things.
* If you have lots of associations, it gets more complicated. You may just
want to put the association-related stuff in the main DB class, or put the
association stuff in each class that has the association, or make separate
association classes and make a DB interface for each association class.
For example, you might have something like this:
package Airplane;
sub takeoff {}
sub land {}
sub change_destination {}
package DB;
sub connect { #this would be constructor }
sub disconnect {}
sub start_transaction {}
sub finish_transaction {}
package DB::Airplane
sub insert {}
sub delete {}
sub getByAltitude {}
sub getBySpeed {}
sub getByDestination {}
sub getByAny {}
Dealing with associations and inheritance is complicated and annoying, but
can be done. If you want to roll your own, I suggest you do a search on
google for OO RDBMS mapping layer, or ask some questions in comp.object.
However, it is much easier to just use Tangram; all that suff is already
done for you. =)
> Has anyone ever done anything like this before? Do you have any comments
> about this technique?
I have been using Tangram and Template-Toolkit to develop a webapp, so far,
so good. =) The main problem is that it is a pain the the butt to have to
remake the Tangram "schema" (object model) every time I do any significant
refactoring.
-Mike
--caemblchncchjijjfifc--
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Object Oriented Databases with MySQL
Posted by Chris Winters <ch...@cwinters.com>.
* Philip Mak (pmak@aaanime.net) [010613 18:21]:
> Hello all,
>
> I've been experimenting with a programming technique idea I had that I
> call "Object Oriented Databases". The goal of the technique is to make
> programming database driven websites easier by allowing the website code
> (I use Apache::ASP, which is built on mod_perl) to access the database
> contents as objects rather than having to write SQL statements. (The SQL
> statements are in the .pm files that define the objects' methods.)
Hi Philip,
You might also be interested in SPOPS (Simple Perl Object Persistence
with Security). Nothing illustrates the point like code, so here's
some sample code. The file 'object_info.perl' contains configuration
information for the objects 'author' and 'fanfics'.
use strict;
use SPOPS::Initialize;
SPOPS::Initialize->process({ filename => 'object_info.perl' });
my $author_list = Fanfics->fetch_group({ order => 'name' });
foreach my $author ( @{ $author_list }) {
my $fanfics_list = $author->fanfics;
foreach my $fanfic ( @{ $fanfic_list } ) {
print <<<LINK;
<a href="$fanfic->{handle}.html">$fanfic->{title}</a> by
<a href="mailto:$author->{email}">
$author->{name}</a><br>
LINK
}
}
You could just as easily reverse the list and fill $fanfics_list
first, then for each fanfics find its author.
One of the best points is that you don't even need to modify your
database schema -- just create configuration information for the
object, run SPOPS::Initialize on it and the necessary classes are
created for you behind the scenes.
SPOPS also makes this trivial to move this data from one datastore
(MySQL) to another (PostgreSQL, or any other supported database) just
by modifying a line in the configuration.
The next version of SPOPS (0.41) will also support iterators which
will make the above code much more efficient memory-wise. (I just
finished writing the code while at YAPC North America -- a very
fertile environment!)
If you're interested, SPOPS is on CPAN, and you can join the
openinteract-help or -dev mailing lists (which provide support and
discussion for SPOPS) at:
http://sourceforge.net/mail/?group_id=16810
Hope this helps!
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Object Oriented Databases with MySQL
Posted by Michael A Mayo <mi...@worldnet.att.net>.
----- Original Message -----
From: "Philip Mak" <pm...@aaanime.net>
To: <db...@perl.org>
> I've been experimenting with a programming technique idea I had that I
> call "Object Oriented Databases". The goal of the technique is to make
> programming database driven websites easier by allowing the website code
> (I use Apache::ASP, which is built on mod_perl) to access the database
> contents as objects rather than having to write SQL statements. (The SQL
> statements are in the .pm files that define the objects' methods.)
OODBMS is not a new idea; they have been around for a long time. You might
want to take a look at comp.object or comp.databases.object. However, many
people still want to use an RDBMS for storage for various reasons, but use
OO programming techniques and pretend they are dealing with an OODBMS. So,
they construct an OO<-->RDBMS mapping layer that looks like an interface to
an OODBMS, but translates that to RDBMS commands.
In another language, you might have to pay big $$ for an RDBMS<->OO mapping
layer. In Perl, however, we are lucky to have the excellent and free
Tangram. It does pretty much everything you would want an OO<-->RDBMS
mapping layer to do, except for support for changes in the object model.
You don't even have to inherit all your persistant classes from a base class
or any other similar magic.
Take a look at the Guided Tour: www.tangram-persistence.org
> One of the early problems I'm running into with this style of programming
> is that the flexibility of the MySQL queries is somewhat limited. In a
> database driven website where the relationships between the database
> tables/entities are well defined and known in advance, ad hoc queries are
> probably not needed so that the design of the *.pm files can account for
> every possible query that may need to be executed.
Building an OO::RDBMS mapping layer is a little complicated, and you are not
doing it correctly.
What you want to do is this:
* Make your object model normally, without any thought to the DBMS, so that
it is not depenant on the DBMS
* For each class, make a separate DB interface class that deals with storing
and retriving objects of that class. Make a main DB class that deals with
connecting to the database and other DB-related things.
* If you have lots of associations, it gets more complicated. You may just
want to put the association-related stuff in the main DB class, or put the
association stuff in each class that has the association, or make separate
association classes and make a DB interface for each association class.
For example, you might have something like this:
package Airplane;
sub takeoff {}
sub land {}
sub change_destination {}
package DB;
sub connect { #this would be constructor }
sub disconnect {}
sub start_transaction {}
sub finish_transaction {}
package DB::Airplane
sub insert {}
sub delete {}
sub getByAltitude {}
sub getBySpeed {}
sub getByDestination {}
sub getByAny {}
Dealing with associations and inheritance is complicated and annoying, but
can be done. If you want to roll your own, I suggest you do a search on
google for OO RDBMS mapping layer, or ask some questions in comp.object.
However, it is much easier to just use Tangram; all that suff is already
done for you. =)
> Has anyone ever done anything like this before? Do you have any comments
> about this technique?
I have been using Tangram and Template-Toolkit to develop a webapp, so far,
so good. =) The main problem is that it is a pain the the butt to have to
remake the Tangram "schema" (object model) every time I do any significant
refactoring.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Object Oriented Databases with MySQL
Posted by Chris Winters <ch...@cwinters.com>.
* Philip Mak (pmak@aaanime.net) [010613 18:21]:
> Hello all,
>
> I've been experimenting with a programming technique idea I had that I
> call "Object Oriented Databases". The goal of the technique is to make
> programming database driven websites easier by allowing the website code
> (I use Apache::ASP, which is built on mod_perl) to access the database
> contents as objects rather than having to write SQL statements. (The SQL
> statements are in the .pm files that define the objects' methods.)
Hi Philip,
You might also be interested in SPOPS (Simple Perl Object Persistence
with Security). Nothing illustrates the point like code, so here's
some sample code. The file 'object_info.perl' contains configuration
information for the objects 'author' and 'fanfics'.
use strict;
use SPOPS::Initialize;
SPOPS::Initialize->process({ filename => 'object_info.perl' });
my $author_list = Fanfics->fetch_group({ order => 'name' });
foreach my $author ( @{ $author_list }) {
my $fanfics_list = $author->fanfics;
foreach my $fanfic ( @{ $fanfic_list } ) {
print <<<LINK;
<a href="$fanfic->{handle}.html">$fanfic->{title}</a> by
<a href="mailto:$author->{email}">
$author->{name}</a><br>
LINK
}
}
You could just as easily reverse the list and fill $fanfics_list
first, then for each fanfics find its author.
One of the best points is that you don't even need to modify your
database schema -- just create configuration information for the
object, run SPOPS::Initialize on it and the necessary classes are
created for you behind the scenes.
SPOPS also makes this trivial to move this data from one datastore
(MySQL) to another (PostgreSQL, or any other supported database) just
by modifying a line in the configuration.
The next version of SPOPS (0.41) will also support iterators which
will make the above code much more efficient memory-wise. (I just
finished writing the code while at YAPC North America -- a very
fertile environment!)
If you're interested, SPOPS is on CPAN, and you can join the
openinteract-help or -dev mailing lists (which provide support and
discussion for SPOPS) at:
http://sourceforge.net/mail/?group_id=16810
Hope this helps!
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
--ajiepgnhgdnmjpbfdbhb--
ReSent-Date: Fri, 29 Jun 2001 14:51:04 -0700 (PDT)
ReSent-From: Ask Bjoern Hansen <as...@valueclick.com>
ReSent-To: <as...@perl.apache.org>
ReSent-Subject: Re: Object Oriented Databases with MySQL
ReSent-Message-ID: <Pi...@impatience.valueclick.com>
* Philip Mak (pmak@aaanime.net) [010613 18:21]:
> Hello all,
>
> I've been experimenting with a programming technique idea I had that I
> call "Object Oriented Databases". The goal of the technique is to make
> programming database driven websites easier by allowing the website code
> (I use Apache::ASP, which is built on mod_perl) to access the database
> contents as objects rather than having to write SQL statements. (The SQL
> statements are in the .pm files that define the objects' methods.)
Hi Philip,
You might also be interested in SPOPS (Simple Perl Object Persistence
with Security). Nothing illustrates the point like code, so here's
some sample code. The file 'object_info.perl' contains configuration
information for the objects 'author' and 'fanfics'.
use strict;
use SPOPS::Initialize;
SPOPS::Initialize->process({ filename => 'object_info.perl' });
my $author_list = Fanfics->fetch_group({ order => 'name' });
foreach my $author ( @{ $author_list }) {
my $fanfics_list = $author->fanfics;
foreach my $fanfic ( @{ $fanfic_list } ) {
print <<<LINK;
<a href="$fanfic->{handle}.html">$fanfic->{title}</a> by
<a href="mailto:$author->{email}">
$author->{name}</a><br>
LINK
}
}
You could just as easily reverse the list and fill $fanfics_list
first, then for each fanfics find its author.
One of the best points is that you don't even need to modify your
database schema -- just create configuration information for the
object, run SPOPS::Initialize on it and the necessary classes are
created for you behind the scenes.
SPOPS also makes this trivial to move this data from one datastore
(MySQL) to another (PostgreSQL, or any other supported database) just
by modifying a line in the configuration.
The next version of SPOPS (0.41) will also support iterators which
will make the above code much more efficient memory-wise. (I just
finished writing the code while at YAPC North America -- a very
fertile environment!)
If you're interested, SPOPS is on CPAN, and you can join the
openinteract-help or -dev mailing lists (which provide support and
discussion for SPOPS) at:
http://sourceforge.net/mail/?group_id=16810
Hope this helps!
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
--ajiepgnhgdnmjpbfdbhb--
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Object Oriented Databases with MySQL
Posted by Joshua Chamas <jo...@chamas.com>.
Philip Mak wrote:
>
> Hello all,
>
> I've been experimenting with a programming technique idea I had that I
> call "Object Oriented Databases". The goal of the technique is to make
> programming database driven websites easier by allowing the website code
> (I use Apache::ASP, which is built on mod_perl) to access the database
> contents as objects rather than having to write SQL statements. (The SQL
> statements are in the .pm files that define the objects' methods.)
>
For an OO framework, I believe Alzabo does just what you need.
I'm sure there's others, but this is the one I keep hearing about.
http://alzabo.sourceforge.net/
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks <- Web Link Checking Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: Object Oriented Databases with MySQL
Posted by Philip Mak <pm...@aaanime.net>.
On Wed, 13 Jun 2001, Sterin, Ilya wrote:
> > One of the early problems I'm running into with this style of programming
> > is that the flexibility of the MySQL queries is somewhat limited.
>
> You have to define what you mean by limited. No foreign constraints? They
> are now availble with the new mysql release, but you must use BSD tables.
> See www.mysql.com. What else is limiting?
No, the limitation is not due to MySQL, but it is due to the fact that in
this programming technique, there is to be no MySQL statements in the main
code of the website. All MySQL access is to be done through the object
oriented interface ("use Fanfic;" in my example).
Thus, any queries that the website needs must be provided for from the
object oriented interface.
-Philip Mak (pmak@aaanime.net)
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: Object Oriented Databases with MySQL
Posted by "Sterin, Ilya" <Is...@ciber.com>.
> -----Original Message-----
> From: Philip Mak [mailto:pmak@aaanime.net]
> Sent: Wednesday, June 13, 2001 7:07 PM
> To: dbi-users@perl.org
> Cc: asp@perl.apache.org
> Subject: Object Oriented Databases with MySQL
>
>
> Hello all,
>
> I've been experimenting with a programming technique idea I had that I
> call "Object Oriented Databases". The goal of the technique is to make
> programming database driven websites easier by allowing the website code
> (I use Apache::ASP, which is built on mod_perl) to access the database
> contents as objects rather than having to write SQL statements. (The SQL
> statements are in the .pm files that define the objects' methods.)
>
> I'm using this technique to develop shoujoai.com, a site that hosts
> stories written by various online authors. There is a table called
> "authors" that has fields such as "name" and "email". There is a table
> called "fanfics" containing the stories, which is linked to the "authors"
> table by the "aid" (author id number) field.
>
> In perl/MySQL, if I wanted to list all the stories, along with their
> authors, I would have to do something like:
>
> my $sth = query("SELECT * FROM fanfics, authors
> WHERE fanfics.aid = authors.aid
> ORDER BY fanfics.title");
> while (my $row = $sth->fetchrow_hashref) {
> print "<a href=\".$row->{handle}.".html\">".$row->{title}."</a> by".
> "<a href=\"mailto:".$row->{email}."\">".
> $row->{name}."</a><br>\n";
> }
>
> In an object oriented style, I would do:
>
> use Fanfics;
> my @fanfics = Fanfics::loadall();
> for my $fanfic (@fanfics) {
> print "<a href=\".$fanfic->handle.".html\">".$fanfic->title."</a> by".
> "<a href=\"mailto:".$fanfic->author->email."\">".
> $fanfic->author->name."</a><br>\n";
> }
>
> In the object oriented version, the resulting code is simpler (I don't
> have to write MySQL statements in there). This simple example doesn't show
> the full potential of this technique, because all the fields in the
> database are simple ones - I don't have to combine data from multiple rows
> in order to get a single piece of information about an entity.
>
> Fanfic.pm would look something like this:
>
> sub loadall {
> my $sth = query("SELECT * FROM fanfics ORDER BY title");
> my @fanfics;
> while (my $row = $sth->fetchrow_hashref) {
> push(@fanfics, bless($row));
> }
> return @fanfics;
> }
>
> sub title {
> my $self = shift;
> if (@_) { $self->{title} = shift }
> return Apache::Util::escape_html($self->{title});
> }
>
> sub author {
> my $self = shift;
> return Author::loadaid($self->{aid});
> }
>
> One of the early problems I'm running into with this style of programming
> is that the flexibility of the MySQL queries is somewhat limited.
You have to define what you mean by limited. No foreign constraints? They
are now availble with the new mysql release, but you must use BSD tables.
See www.mysql.com. What else is limiting?
Ilya
In a
> database driven website where the relationships between the database
> tables/entities are well defined and known in advance, ad hoc queries are
> probably not needed so that the design of the *.pm files can account for
> every possible query that may need to be executed.
>
> Has anyone ever done anything like this before? Do you have any comments
> about this technique?
>
> Thanks,
>
> -Philip Mak (pmak@aaanime.net)
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org