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

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?

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=$username
AND password=$password";
$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($_POST['un'], $_POST['pw']);
if (!$logged_in_user)
echo "Login failed.";

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.

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.

class DB_table
{
protected static fields;
protected static fieldSpecs;

// some __constructor etc...

public function getFieldSpecs( $f )
{
if( isset( self::fieldSpecs[ $f ] ) )
{
return self::fieldSpecs[ $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...
);
}

"Toby A Inkster" <us**********@tobyinkster.co.ukschreef in bericht
news:rr************@ophelia.g5n.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::fieldSpecs[ $f ] ) )
{
return self::fieldSpecs[ $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->getFieldSpecs( 'id' ) );

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

parent::$fieldSpecs = 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.

"Toby A Inkster" <us**********@tobyinkster.co.ukschreef in bericht
news:rr************@ophelia.g5n.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::fieldSpecs[ $f ] ) )
{
return self::fieldSpecs[ $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->getFieldSpecs( 'id' ) );

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

parent::$fieldSpecs = 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 wrote:

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.

amygdala wrote:

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

"Jerry Stuckle" <js*******@attglobal.netschreef 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::$fieldSpecs 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!

"Jerry Stuckle" <js*******@attglobal.netschreef 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.

amygdala wrote:

>"Jerry Stuckle" <js*******@attglobal.netschreef 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::$fieldSpecs 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!

OK, now how are you going to validate the entry? For instance - if you
have a date field, ensure they put a date in there? Or an integer?

Classes also need to be responsible for their own variables. There should
be no way you can ever set an invalid value in any member.

So you might as well get used to writing the set and get functions. They
go pretty quickly (unless you have some extensive validation), and in the
long run it's a much better way to go.

I've been doing OO programming for almost 20 years now, and yes, I've seen
your way before. It ends up being cumbersome and highly prone to errors.
It also creates a maintenance nightmare. You *really* don't want to go
that route.

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.

That OOP stuff is pretty hard to grasp for me

"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:Ub******************************@comcast.com. ..

>amygdala wrote:

>>"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:_L******************************@comcast.co m...
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::$fieldSpecs 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!

OK, now how are you going to validate the entry? For instance - if you
have a date field, ensure they put a date in there? Or an integer?

Well, I would use a generic Validator class for that. Something along the
lines of:

class Validator
{
public function validateField( $fieldName, $fieldValue, $fieldSpecs )
{
switch( $fieldSpec [ 'type' ] )
{
case 'boolean':
// validate boolean
break;
case 'string':
if( isset( $fieldSpec[ 'subtype' ] ) )
{
switch( $fieldSpec[ 'subtype' ] )
{
case 'email':
// validate email
break;
case 'url':
// validate url
break
etc.. etc...
}
}
case 'int':
etc.. etc...

>
For dates I _would_ probably use a custom setter which would convert three
form elements (dd, mm, yyyy) to a unix timestamp (I like those better then
SQL dates) first, but then I would validate its outcome with the generic
Validator also. I could even have some minimal and maximal date values in
$fieldSpecs to check that the date doesn't exceed a certain time span.

For integers I would define some minimal and maximal values in the
$fieldSpecs, and check it directly in the generic Validator. Use is_numeric
and the likes.

>Classes also need to be responsible for their own variables. There should
be no way you can ever set an invalid value in any member.

Of course, I agree with you totally. But I don't see how my approach would
lead to this happening. I would validate each entry just like you do. But
with a generic __set instead of custom setters.

>So you might as well get used to writing the set and get functions. They
go pretty quickly (unless you have some extensive validation), and in the
long run it's a much better way to go.

Maybe you're right. I might be stubborn here. ;-) And off course, I have
thought of the fact that exceptional situations _will_ occur. Probably more
often then I'm thinking off right now. But then that leads me to the
somewhat black and white conclusion stated under your following opinions:

>I've been doing OO programming for almost 20 years now, and yes, I've seen
your way before. It ends up being cumbersome and highly prone to errors.
It also creates a maintenance nightmare. You *really* don't want to go
that route.

I see where you are coming from Jerry, but this point of view then almost
leads me to believe that there is no point in creating DB table objects
whatsoever. Cause then it pretty much comes down to the same old 'linear'
routines again. What then, in your opinion, is the surplus value of creating
DB table classes?

amygdala wrote:

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

OK -- how about this -- you have a Database class, but you want to make
sure that your scripts only ever open a single connection to the database.
You don't want both, say, a User object and an Article object to open
their own individual connections like this:

<?php
class User
{
private $db;
public function __construct ()
{
$this->db = new Database(/*...*/);
}
}
class Article
{
private $db;
public function __construct ()
{
$this->db = new Database(/*...*/);
}
}
?>

And so to prevent this, you make the Database's constructor function
private. This is known as the "singleton" design pattern in the PHP
manual. (It's on the same page as the factory design pattern!)

<?php
class Database
{
public function query ($q) { /*...*/ }
public function type () { /*...*/ }
public function escape_string ($s) { /*...*/ }
private function __construct ($dsn, $username, $password) { /*...*/ }

private static $instance;
public static singleton ($dsn, $username, $password)
{
if (!isset(self::$instance))
self::$instance = new Database ($dsn, $username, $password);

return self::$instance;
}
}
?>

So now you must use "Database::singleton()" instead of "new Database" to
get a database object, but the singleton class method will always return a
pointer to the same Database object -- it won't create a brand new one!

And your code becomes:

<?php
class User
{
private $db;
public function __construct ()
{
$this->db = Database::singleton(/*...*/);
}
}
class Article
{
private $db;
public function __construct ()
{
$this->db = Database::singleton(/*...*/);
}
}
?>

amygdala wrote:

And as you add more types and subtypes, this gets longer and longer. And
slower and slower. And harder to maintain and more subject to errors.

And you'll have to add more custom validators plus hooks for them.

And what about cases where you need non-consecutive numbers? Such as
those from the set (1, 2, 3, 5, 8, 13, 21...)? Another custom
validator...

The generic will be much larger, much slower and much harder to maintain.

Yes, it's easy to get one idea in your mind as the best way and stick to
it too long. You need to be flexible. Even after 40 years of programming
I sometimes have to change my approach because someone shows me a better
way.

I create db objects all the time. But they have get and set functions for
each field (at least the appropriate ones). They are quite handy for a
number of purposes - the biggest one being abstracting the database
access. But then that's their major purpose.

For instance - one I'm on right now. I have a site coded in VBScript
using Access. I want to change it to PHP and MySQL. However, for various
reasons this needs to be done in stages. The Access database has over 30
tables, ranging from 2 columns to over 40 columns per table.

We're (others are involved - it's a big site) creating DB objects to
interface the Access tables. These will handle the actual SQL calls and
isolates the program from the database being used (or even flat files, if
necessary).

Next we'll creating business objects - these objects translate between the
program and the database objects, and convert what's in the tables to a
format the rest of the program needs. This isolates the rest of the code
from the database table design (i.e. if we need to change one or more
tables, this and the db objects are all that will need changing).

We'll then convert sections of the site at a time. Once we get a section
converted, we'll bring it online.

When we're done and can change from the Access database to MySQL, we'll
change the Database layer and move the data. If at the same time we need
to change some of the table design, this will be handled between the
database and business object layers. But any changes will be isolated to
those layers.

Note the business object layer isn't always needed. But due to the
complexity of the site and how many tables are interrelated, we decided it
would be better to use them here.

These are the benefits of database objects (and OO in general).
But I would hate to use your fieldspec idea in this case. It would make
things much harder to troubleshoot, and we'd end up with a lot of
specialized validators. The result would rapidly become unmanageable.

So we're putting in the set and get functions for several hundred table
columns. Additionally, we're doing a similar number on the business
object end. And depending on the data, it may be validated in either
level.

"Jerry Stuckle" <js*******@attglobal.netschreef in bericht
news:mp******************************@comcast.com. ..

>amygdala wrote:

<snip>

>And as you add more types and subtypes, this gets longer and longer. And
slower and slower. And harder to maintain and more subject to errors.

<snip>

>And you'll have to add more custom validators plus hooks for them.

<snip>

>And what about cases where you need non-consecutive numbers? Such as
those from the set (1, 2, 3, 5, 8, 13, 21...)? Another custom
validator...

<snip>

>The generic will be much larger, much slower and much harder to maintain.

<snip>

>Yes, it's easy to get one idea in your mind as the best way and stick to
it too long. You need to be flexible. Even after 40 years of programming
I sometimes have to change my approach because someone shows me a better
way.

<snip>

>I create db objects all the time. But they have get and set functions for
each field (at least the appropriate ones). They are quite handy for a
number of purposes - the biggest one being abstracting the database
access. But then that's their major purpose.

For instance - one I'm on right now. I have a site coded in VBScript
using Access. I want to change it to PHP and MySQL. However, for various
reasons this needs to be done in stages. The Access database has over 30
tables, ranging from 2 columns to over 40 columns per table.

We're (others are involved - it's a big site) creating DB objects to
interface the Access tables. These will handle the actual SQL calls and
isolates the program from the database being used (or even flat files, if
necessary).

Next we'll creating business objects - these objects translate between the
program and the database objects, and convert what's in the tables to a
format the rest of the program needs. This isolates the rest of the code
from the database table design (i.e. if we need to change one or more
tables, this and the db objects are all that will need changing).

We'll then convert sections of the site at a time. Once we get a section
converted, we'll bring it online.

When we're done and can change from the Access database to MySQL, we'll
change the Database layer and move the data. If at the same time we need
to change some of the table design, this will be handled between the
database and business object layers. But any changes will be isolated to
those layers.

Note the business object layer isn't always needed. But due to the
complexity of the site and how many tables are interrelated, we decided it
would be better to use them here.

These are the benefits of database objects (and OO in general).
But I would hate to use your fieldspec idea in this case. It would make
things much harder to troubleshoot, and we'd end up with a lot of
specialized validators. The result would rapidly become unmanageable.

So we're putting in the set and get functions for several hundred table
columns. Additionally, we're doing a similar number on the business
object end. And depending on the data, it may be validated in either
level.

Some darned good points Jerry. Especially the getting too large and slow
parts are starting to convince me

Good point about the flexibility too! I try my best to keep up a flexible
attitude. The thing is though that I often get caught up in trying to
generalize things too much and/or mixing up in what 'layer' certain routines
should take place.

For instance, as you put in your example: Where would validating in the
bussiness objects stop and validating in DB objects start, or vice versa.
Are there some ground rules or methodologies for determining this in early
stages of coding a project? Do you know of some pointers; some good clear
articles perhaps?

Just out of curiousity though. I assume that you _do_ have some sort of
generic validator routines for repeating column / field validation right?
For instance a generic validateEmail() function which you call for the
specific task when doing a setEmail. You're not reinventing the wheel in
each and every getter methods right?

Thanks again!

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.

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?

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>

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?

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.