OOP database tables <-> php interface (semi LONG)

[amygdala]

Hi,

I'm trying to grasp OOP to build an interface using class objects that lets
me access database tables easily. You have probably seen this before, or
maybe even built it yourself at some point in time. I have studied some
examples I found on the internet, and am now trying to build my own from
scratch.

I have made a default table class (DB_Table), a default validation class
(Validator) which is an object inside DB_Table and my final database tables
each get a class: e.g. User, UserProfile, Country, etc that extend the
DB_Table class.

Its something along the lines of (incomplete code, just for demonstration
purpose):

<?php

class DB_Table
{
public function __construct()
{
// intialize object
// initialize (common) validator
$this->validator = new Validator( $this );
}

public function loadData()
{
// get all data from record
}

public function saveData()
{
// save all data to record
}

public function __get( $field )
{
// get object property
}

public function __set( $field, $value )
{
// set object property
}
}

class User extends DB_Table
{
public $dbt = DB_TABLE_USER;

public $fields = array(
'id' =NULL,
'userType' =NULL,
'username' =NULL,
'password' =NULL,
'email' =NULL,
'active' =NULL,
'timeCreated' =NULL,
'timeActivated' =NULL,
'timeUpdated' =NULL
);

public $fieldSpecs = array(
'id' =array(
'screenname' ='user id',
'type' ='int',
'autoinsert' =true,
'autoincrement' =true,
'static' =true
),
'userType' =array(
'type' ='tyniint',
'nodisplay' =true
),
'username' =array(
'screenname' ='username',
'type' ='string',
'unique' =true,
'required' =true,
'static' =true,
),
// etc...
);
}

?>

It definately still needs a lot of tayloring for it to even work smoothly
for straightforward DB tables. But besides that, a few future issues are
bothering me already:

For instance, take the class User: let's say somebody registers at my site.
This person fills in the details. The Validator class checks each field
seperately. No problem. A new User record is inserted in the database.

But what now, if a user wants to login to the system after the user is
registrated?
I would create an instance of class User. Asign the credential values to the
object. And let the Validator class do its work again.
But, if a user logs in with incorrect credentials, I don't want to report
back to the user whether he/she filled in an incorrect username or an
incorrect password. No, I only want to report back that he/she has filled in
wrong credentials.

But the Validator class only checks each field seperately. In order to keep
the Validator class as common as possible would you build a seperate Login
class for instance? A class that has some custom validation methods? Or
perhaps just insert custom validation methods in the User class? I myself
just cannot seem to make up my mind in this case. Probably cause I'm still
too inexperienced when it comes to OOP programming.

A few other minor questions come to mind also:
- My gut feeling tells me it is wise to make a reference to the Validator
class inside DB_Table, e.g:
$this->validator =& new Validator( $this );
.... because it only creates a single instance of the object, right?

- And why can't I refer to a private variable in DB_Table from an extended
class (such as User)? I would asume, that this private variable, declared in
the parent object, is now a private variable in User also, no?

- And last but not least, is there a way for me to access let's say User
properties from the Validator class without having to pass $this as an
argument to:
$this->validator = new Validator( $this );
.... I know the following to be incorrect, but I was thinking of something
like the keyword parent.

I hope these questions and examples make sense to you and hopefully someone
can shed a light on these issues. Thank you in advance for your time.

Cheers

[amygdala]

"Toby A Inkster" <us**********@t obyinkster.co.u kschreef in bericht
news:dc******** ****@ophelia.g5 n.co.uk...

amygdala wrote:

>Since I would like to have only one database handler that can be accessed
by
both the constructor and the factory method (?) getUserById() I decided
to
declare $dbh static. Does this make sense?

It makes sense, but a better solution would be to make your database
object into a singleton class. That is, similar to the Database object
here:

http://message-id.net/<r1************ @ophelia.g5n.co .uk>

Well, that is the case already. Perhaps it was a bit confusion because I
named the method in the Database object getInstance. I've changed it to
getSingleton now. (See below).

But that still doesn't allow me to create the $dbh only once at the
beginning of the User class like so:

class User
{
private $dbh = Database::getSi ngleton( /* */ );

private function __construct() {}

public static function getUserById()
{
// use self::$dbh here
}

public function saveUser()
{
// use self::$dbh here
}
}

Mind you, it's not a big issue, merely a cosmetic one. What I am still
struggeling more with is the registrate function. Would you consider that a
User class method. Or should it be in some other object. Or perhaps just be
a regular function in the global script?
// class Database code:

class Database
{
protected static $dbh;

private function __construct() {}

public static function getSingleton( $interface, $host, $schema, $username,
$password )
{
if ( !isset( self::$dbh ) )
{
self::$dbh = new PDO( ( $interface . ':host=' . $host . ';dbname=' .
$schema ), $username, $password );
self::$dbh->setAttribute ( PDO::ATTR_ERRMO DE, PDO::ERRMODE_EX CEPTION );
//self::$dbh->setAttribute ( PDO::MYSQL_ATTR _USE_BUFFERED_Q UERY, TRUE );
}
return self::$dbh;
}

public function __destruct()
{
if ( isset( self::$dbh ) )
{
self::$dbh = NULL;
}
}
}

[Toby A Inkster]

amygdala wrote:

Mind you, it's not a big issue, merely a cosmetic one. What I am still
struggeling more with is the registrate function. Would you consider that a
User class method. Or should it be in some other object. Or perhaps just be
a regular function in the global script?

It could be implemented as a regular function, but I'd tend to put it as a
static factory function in the User class. (i.e. it returns the newly
registered User as an object -- much like the static login function
would.) This has the benefit of having internal consistency with the login
function. (A developer familiar with the login function would have little
trouble picking up the registration function.) Also, it keeps the function
"wrapped up" in the User class, so that everything is kept in one place.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

[amygdala]

"Toby A Inkster" <us**********@t obyinkster.co.u kschreef in bericht
news:go******** ****@ophelia.g5 n.co.uk...

amygdala wrote:

>Mind you, it's not a big issue, merely a cosmetic one. What I am still
struggeling more with is the registrate function. Would you consider that
a
User class method. Or should it be in some other object. Or perhaps just
be
a regular function in the global script?

It could be implemented as a regular function, but I'd tend to put it as a
static factory function in the User class. (i.e. it returns the newly
registered User as an object -- much like the static login function
would.) This has the benefit of having internal consistency with the login
function. (A developer familiar with the login function would have little
trouble picking up the registration function.) Also, it keeps the function
"wrapped up" in the User class, so that everything is kept in one place.

Alright Toby, that is reassuring. Thanks for the input.