Jeff 'japhy' Pinyan wrote:
On Jul 13, Scott R. Godin said:
The original object itself is at
http://www.webdragon.net/miscel/Subscriber.pm
[snip]
Additionally uploaded my skeleton starting ideas on Subscriber::DB at
http://www.webdragon.net/miscel/DB.pm
All Subscriber::DB objects would share the DBI object -- there's no need
for a billion database handles.
ok, so possibly one should do it differently than I have, in my example.
> I would also make Subscriber::DB
> inherit from Subscriber... for a reason I'll show you in a moment.
If you're making a NEW object (that is, not loading from the DB),
perhaps you should make that the function of the 'new' method, and leave
restoring objects from the DB to a different method, such as 'load' or
'restore'.
right, now that at least makes good sense to me, and clearly separates
the two functions.
my $x = Subscriber::DB->new(fname => "Jean", lname => "Valjean");
# vs.
my $y = Subscriber::DB->load(id => 24601);
# or
my $y = Subscriber::DB->new_from_id(24601);
These objects themselves should be hollow -- that is, they should only
contain as much as is needed to retrieve their data from the database.
In your case, I would guess that means just their id.
Maybe.. this might be where my understanding of these things has gone
agley, but I'd envisioned it somewhat differently..
One thing I'd thought of recently would be to have a __DATA__ section
populated with a number of SQL queries (with placeholders) and a
shortname to identify it with, that I could call on at will.
But what I had thought of doing would be to populate the object via the
database and fill it entire, thus being able to call any of the
Subscriber methods on it without generating multiple calls to the
database for each one. (this could prove important in a template-driven
environment. Additionally the ultimate target of this will be a website
interface (user/admin) so that affects part of the picture too -- should
I even be considering at this point whether or not to plan ahead towards
mod_perl ? )
Then, when you do $y->get_greeting(), perhaps you want to do something
like:
# here's a global variable for all of Subscriber::DB
my $greeting_sql = $DBH->prepare(q{
SELECT salutation, firstname, lastname
FROM subscriber_db
WHERE id = ?
});
# Subscriber::DB::get_greeting
sub get_greeting {
my ($self) = @_;
my $id = $self->{_id};
$greeting_sql->bind_columns(
\$self->{_salutation},
\$self->{_firstname},
\$self->{_lastname},
);
$greeting_sql->execute($id);
# now here is the magic!
return $self->SUPER::get_greeting;
}
This is where the inheritence counts. Subscriber::DB::get_greeting
merely populates enough of the hash for Subscriber::get_greeting to
operate correctly. The bind_columns() call tells the SQL statement to
populate those values (values in a hash) when it gets executed.
Admittedly that is a neat idea (and now I see how the SUPER:: bit works
into the picture, but as my comment above suggested, I'd like to avoid
too many calls to the database if at all possible.
Now, if you had your Subscriber::AUTOLOAD set up, we could rewrite this as:
sub get_greeting {
my ($self) = @_;
my $id = $self->{_id};
$greeting_sql->bind_columns(\my ($salut, $fname, $lname));
$greeting_sql->execute($id);
$self->set_salutation($salut);
$self->set_firstname($fname);
$self->set_lastname($lname);
# magic as usual
return $self->SUPER::get_greeting;
}
*OR*, if you had Subscriber::set() like I showed, you could do:
[snip]
$self->set(
_salutation => $salut,
_firstname => $fname,
_lastname => $lname,
);
# magic as usual
return $self->SUPER::get_greeting;
}
One problem-space I'm still trying to wrap into the picture is the need
to be able to grab data from the database based on different criterion..
for example "everyone who has requested info by e-mail only", or the
opposite -- people who want their info snail-mailed to them.
so while iterating through the data-set resulting from the sql search,
the subscriber object gets populated with each, and then used to
generate the mailing labels, or the list of e-mails to be wrapped up and
used by the mailing list manager (NOT spamming but a special use list,
akin to Mail::SimpleList or that used by mailman (which is yet another
problem space of the project -- a Subscriber::Mailer thingy I'm still
pondering, but that's a later thing -- first the Database stuff. :)
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
