Re^3: Structure of a custom class (using Apache::Session)

I simply meant specifying the connection information in one location (the class)

um? The connection info isn't in the class. It's still in the class's user, just like it would be if Apache::Session::MySQL had been used directly.

my $session_obj = Local::WPSession->new(dbh => $dbh, id => $sid);
#                                              ^^^^
[download]

If you want to move the info needed to create the dbh into Local::WPSession (and possibly even create the dbh within the new class as well), why not make Local::WPSession inherit from Apache::Session::MySQL and simply override the constructor? That way, the user will be able to access all of Apache::Session::MySQL's methods without forcing you to recreate the interface or to create a new interface.

Comment on Re^3: Structure of a custom class (using Apache::Session) Download Code

Replies are listed 'Best First'.
Re^4: Structure of a custom class (using Apache::Session) by jeyroz (Monk) on Jun 15, 2005 at 20:11 UTC
Ikagami, thanks again for your response! I am indeed passing $dbh into my class but the connection details are specified in the class itself. While it's convenient to use my existing db handle in this example, it won't always be available to pass. In that case I would certainly move the actual db connection into the class itself ... my fault for not stating that. Also, there is a possibility that the session data may not be stored in the same database that the application uses. In this case there would be a bit more information needed to establish the connection. I figured keeping this separate would save me some touble. Let me know if this still seems wasteful. I like your suggestion to simply override the constructor. author => jeyroz	[reply]

Replies are listed 'Best First'.

Re^4: Structure of a custom class (using Apache::Session)
by jeyroz (Monk) on Jun 15, 2005 at 20:11 UTC

Ikagami, thanks again for your response!

I am indeed passing $dbh into my class but the connection details are specified in the class itself. While it's convenient to use my existing db handle in this example, it won't always be available to pass. In that case I would certainly move the actual db connection into the class itself ... my fault for not stating that. Also, there is a possibility that the session data may not be stored in the same database that the application uses. In this case there would be a bit more information needed to establish the connection. I figured keeping this separate would save me some touble. Let me know if this still seems wasteful.

I like your suggestion to simply override the constructor.

author => jeyroz

[reply]