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

[Toby A Inkster]

amygdala wrote:

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?

class User
{
public static logon ($username, $password)
{
// Example query. You will want to protect against SQL
// injection here.
$q = "SELECT blah
FROM blah
WHERE username=$usern ame
AND password=$passw ord";
$result = run_query($q);

if (!$result)
return NULL;

$user = new User;
$user->load_data(/* blah */);
return $user;
}
}

This is an example of a User "factory". See "factory design pattern" in the
PHP manual. To use it:

$logged_in_user = User::logon($_P OST['un'], $_POST['pw']);
if (!$logged_in_us er)
echo "Login failed.";

--
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:jd******** ****@ophelia.g5 n.co.uk...

amygdala wrote:

>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?

class User
{
public static logon ($username, $password)
{
// Example query. You will want to protect against SQL
// injection here.
$q = "SELECT blah
FROM blah
WHERE username=$usern ame
AND password=$passw ord";
$result = run_query($q);

if (!$result)
return NULL;

$user = new User;
$user->load_data(/* blah */);
return $user;
}
}

This is an example of a User "factory". See "factory design pattern" in
the
PHP manual. To use it:

$logged_in_user = User::logon($_P OST['un'], $_POST['pw']);
if (!$logged_in_us er)
echo "Login failed.";

Thanks for the response and the pointer.

I'm a little confused about the 'factory design pattern' though. Let me see
if I understand this correctly. Does the factory design pattern in this case
refer to the fact that you have different interfaces in one Class (in this
case class User) to create the object, depending on the purpose it serves.

So I could do a:

$blank_user = new User();

or I could do a

$logged_in_user = User::logon($_P OST['un'], $_POST['pw']);

which both return a User object?

[Toby A Inkster]

amygdala wrote:

I'm a little confused about the 'factory design pattern' though. Let me see
if I understand this correctly. Does the factory design pattern in this case
refer to the fact that you have different interfaces in one Class (in this
case class User) to create the object, depending on the purpose it serves.

Yep, precisely. You create a static method to produce an object which
would normally go further than the plain constructor function in terms of
setting object properties.

On some occasions you may even want to make the main constructor method
for the class private instead of public to force all objects to be created
via the factory.

--
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:rr******** ****@ophelia.g5 n.co.uk...

amygdala wrote:

>I'm a little confused about the 'factory design pattern' though. Let me
see
if I understand this correctly. Does the factory design pattern in this
case
refer to the fact that you have different interfaces in one Class (in
this
case class User) to create the object, depending on the purpose it
serves.

Yep, precisely. You create a static method to produce an object which
would normally go further than the plain constructor function in terms of
setting object properties.

On some occasions you may even want to make the main constructor method
for the class private instead of public to force all objects to be created
via the factory.

Nice one! That's excellent stuff.
In the meantime I read a little further on the factory stuff, and indeed saw
that you could make the constructor method private. Could you by any chance
provide the simplest example of an occassion where making the constructor
private makes sense? Cause I can't think of a valuable situation right now.
But I'm interested in understanding where this would make sense. (That OOP
stuff is pretty hard to grasp for me)

Another thing I am trying to accomplish is the following: (still the same
'framework')

What would be ideal for me is if I had table classes derived from the
'template' DB_Table that would only describe table fields and their
properties. And for the most part let the parent DB_Table handle all the
generic methods for tweaking fields. Except of course a function such as
login, as discussed earlier.

What would seem important here also, is to have as little public methods and
properties as possible. So if you will, consider the following:

class DB_table
{
protected static fields;
protected static fieldSpecs;

// some __constructor etc...

public function getFieldSpecs( $f )
{
if( isset( self::fieldSpec s[ $f ] ) )
{
return self::fieldSpec s[ $f ];
}
else
{
return NULL;
}
}
}

class User extends DB_Table
{
protected static fieldSpecs = array(
'id' =array(
'article' ='a',
'screenname' ='user id',
'type' ='int',
'autoinsert' =true,
'autoincrement' =true,
'static' =true
),
etc...
);
}

What I would like to happen is that when I do a:

$u = new User();
var_dump( $u->getFieldSpec s( 'id' ) );

it would return the 'fieldSpecs' from the 'id' in User. But this doesn't
seem to work.

parent::$fieldS pecs = array( etc...

doesn't seem to work either.

Is there any way to get this working without having to declare fieldSpecs
public and/or having to overload (I think it is what it's called) the
'getFieldSpecs' function from within User?

In other words, how can I overwrite the 'protected static fieldSpecs' of
DB_Table from within User so that 'getFieldSpecs' in DB_Table returns its
values? Or is this against OOP principles?
Cheers.

[amygdala]

>

class DB_table
{
protected static fields;
protected static fieldSpecs;

// some __constructor etc...

public function getFieldSpecs( $f )
{
if( isset( self::fieldSpec s[ $f ] ) )
{
return self::fieldSpec s[ $f ];
}
else
{
return NULL;
}
}
}

class User extends DB_Table
{
protected static fieldSpecs = array(
'id' =array(
'article' ='a',
'screenname' ='user id',
'type' ='int',
'autoinsert' =true,
'autoincrement' =true,
'static' =true
),
etc...
);
}

Oops; dollarsigns where needed of course. :-S

[Jerry Stuckle]

amygdala wrote:

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

>amygdala wrote:

>>I'm a little confused about the 'factory design pattern' though. Let me
see
if I understand this correctly. Does the factory design pattern in this
case
refer to the fact that you have different interfaces in one Class (in
this
case class User) to create the object, depending on the purpose it
serves.

Yep, precisely. You create a static method to produce an object which
would normally go further than the plain constructor function in terms of
setting object properties.

On some occasions you may even want to make the main constructor method
for the class private instead of public to force all objects to be created
via the factory.

Nice one! That's excellent stuff.
In the meantime I read a little further on the factory stuff, and indeed saw
that you could make the constructor method private. Could you by any chance
provide the simplest example of an occassion where making the constructor
private makes sense? Cause I can't think of a valuable situation right now.
But I'm interested in understanding where this would make sense. (That OOP
stuff is pretty hard to grasp for me)

Another thing I am trying to accomplish is the following: (still the same
'framework')

What would be ideal for me is if I had table classes derived from the
'template' DB_Table that would only describe table fields and their
properties. And for the most part let the parent DB_Table handle all the
generic methods for tweaking fields. Except of course a function such as
login, as discussed earlier.

What would seem important here also, is to have as little public methods and
properties as possible. So if you will, consider the following:

class DB_table
{
protected static fields;
protected static fieldSpecs;

// some __constructor etc...

public function getFieldSpecs( $f )
{
if( isset( self::fieldSpec s[ $f ] ) )
{
return self::fieldSpec s[ $f ];
}
else
{
return NULL;
}
}
}

class User extends DB_Table
{
protected static fieldSpecs = array(
'id' =array(
'article' ='a',
'screenname' ='user id',
'type' ='int',
'autoinsert' =true,
'autoincrement' =true,
'static' =true
),
etc...
);
}

What I would like to happen is that when I do a:

$u = new User();
var_dump( $u->getFieldSpec s( 'id' ) );

it would return the 'fieldSpecs' from the 'id' in User. But this doesn't
seem to work.

parent::$fieldS pecs = array( etc...

doesn't seem to work either.

Is there any way to get this working without having to declare fieldSpecs
public and/or having to overload (I think it is what it's called) the
'getFieldSpecs' function from within User?

In other words, how can I overwrite the 'protected static fieldSpecs' of
DB_Table from within User so that 'getFieldSpecs' in DB_Table returns its
values? Or is this against OOP principles?
Cheers.

Definitely properties should be private. They're part of the
implementation.

However, I often have lots of public methods. For instance, I'll have a
getXXX method to fetch 'xxx'. And I may have a setxxx method to set it,
if that makes sense - the latter doing validation on the parameter
passed, if necessary.

So potentially in a table with 25 columns I can have 25 getXXX and 25
setXXX methods (and 25 private variables, one for each column), database
related methods, etc. This can easily come out to 60-70 public methods
- and often I'll have some private ones, also.

But don't try to put all of your variables in one 'fieldspec' array.
While it will work, it will also be almost impossible to understand
later and even worse to maintain.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Jerry Stuckle]

amygdala wrote:

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

>amygdala wrote:

>>I'm a little confused about the 'factory design pattern' though. Let me
see
if I understand this correctly. Does the factory design pattern in this
case
refer to the fact that you have different interfaces in one Class (in
this
case class User) to create the object, depending on the purpose it
serves.

Yep, precisely. You create a static method to produce an object which
would normally go further than the plain constructor function in terms of
setting object properties.

On some occasions you may even want to make the main constructor method
for the class private instead of public to force all objects to be created
via the factory.

Nice one! That's excellent stuff.
In the meantime I read a little further on the factory stuff, and indeed saw
that you could make the constructor method private. Could you by any chance
provide the simplest example of an occassion where making the constructor
private makes sense? Cause I can't think of a valuable situation right now.
But I'm interested in understanding where this would make sense. (That OOP
stuff is pretty hard to grasp for me)

Another thing I am trying to accomplish is the following: (still the same
'framework')

What would be ideal for me is if I had table classes derived from the
'template' DB_Table that would only describe table fields and their
properties. And for the most part let the parent DB_Table handle all the
generic methods for tweaking fields. Except of course a function such as
login, as discussed earlier.

What would seem important here also, is to have as little public methods and
properties as possible. So if you will, consider the following:

class DB_table
{
protected static fields;
protected static fieldSpecs;

// some __constructor etc...

public function getFieldSpecs( $f )
{
if( isset( self::fieldSpec s[ $f ] ) )
{
return self::fieldSpec s[ $f ];
}
else
{
return NULL;
}
}
}

class User extends DB_Table
{
protected static fieldSpecs = array(
'id' =array(
'article' ='a',
'screenname' ='user id',
'type' ='int',
'autoinsert' =true,
'autoincrement' =true,
'static' =true
),
etc...
);
}

What I would like to happen is that when I do a:

$u = new User();
var_dump( $u->getFieldSpec s( 'id' ) );

it would return the 'fieldSpecs' from the 'id' in User. But this doesn't
seem to work.

parent::$fieldS pecs = array( etc...

doesn't seem to work either.

Is there any way to get this working without having to declare fieldSpecs
public and/or having to overload (I think it is what it's called) the
'getFieldSpecs' function from within User?

In other words, how can I overwrite the 'protected static fieldSpecs' of
DB_Table from within User so that 'getFieldSpecs' in DB_Table returns its
values? Or is this against OOP principles?
Cheers.

One other thing - the class members shouldn't be static. Static members
are shared by all objects of the class. So if you have two objects of
this class and change it in one, both will change.

Non-static data members are unique to each instantiation of the class.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[amygdala]

"Jerry Stuckle" <js*******@attg lobal.netschree f in bericht
news:_L******** *************** *******@comcast .com...

amygdala wrote:

<snip>

Definitely properties should be private. They're part of the
implementation.

However, I often have lots of public methods. For instance, I'll have a
getXXX method to fetch 'xxx'. And I may have a setxxx method to set it,
if that makes sense - the latter doing validation on the parameter passed,
if necessary.

So potentially in a table with 25 columns I can have 25 getXXX and 25
setXXX methods (and 25 private variables, one for each column), database
related methods, etc. This can easily come out to 60-70 public methods -
and often I'll have some private ones, also.

Well, this is just exactly what I am trying to avoid. I have (unfinished)
__get and __set methods in the base class DB_Table that should take care of
this in one go.

But don't try to put all of your variables in one 'fieldspec' array. While
it will work, it will also be almost impossible to understand later and
even worse to maintain.

Hmm, you are no doubt much more experienced in this field, but my gutfeeling
says I have to disagree on this one. The whole point of creating this
framework for me is to avoid the cumbersome task of creating getter and
setter functions for each and every table field. Thus I'm declaring one
generic fieldSpecs array that provides properties for the fields so that the
generic getters and setters as well as the generic Validator will take care
of the rest. I don't see the fieldSpecs array becoming to difficult to
understand quickly for me in the future.

Still, this leaves me wondering: why doesn't a child class just simply
inherite the 'getFieldSpecs' function and let self::$fieldSpe cs refer to the
$fieldSpecs in the child class? Should this not be the basics of OOP? What
am I missing here? Or better yet: how can this be achieved?

Thanks for your time people. Much appreciated!

[amygdala]

"Jerry Stuckle" <js*******@attg lobal.netschree f in bericht
news:_L******** *************** *******@comcast .com...

amygdala wrote:

<snip>

>
One other thing - the class members shouldn't be static. Static members
are shared by all objects of the class. So if you have two objects of
this class and change it in one, both will change.

Non-static data members are unique to each instantiation of the class.

Aaah yes of course. Silly me. Good point. I overlooked that one.

But would it be save to say that a derived class of DB_Table such as User
_could_ have a static $fields variable (for instance when I wont be
declaring it in the parent class first), since every User instance would
have the same table fields?

Thanks again Jerry et al.