Whoa....it looks more like a network than a library of classes
Your over complicating things...
There is no need to:
1) Derive anything from database classes...it's likely most objects which need DB support have a has_a relationship with the DB class not a is_a
That is...they are
not a database objet, they only need it's functionality...there is no point to extending the database class. The only time I can think of when one might, is in writting a DB abstraction layer...
If for some reason, you wanted the data store to be bound to your subclass at object instantiation instead of dynamically (sorta) via a connect() you could derive your sub class from a database superclass...
Also, if in your subclass, you wanted to inherit the super class API...for specialized functions (ex: perhaps MySQL and MSSQL used a different connect parameters)
Code: Select all
1) MySQL: connect($user, $pass, $host);
2) MSSQL: connect($pass, $user, $host);
Notice the difference in function signatures?
MySQL and MSSQL would be your super classes and MineDB would be your subclass which
derived from MySQL or MSSQL depending on a define you specified or something similar.
You would use inheritance here, because you need to
inherit the interface for connections specific to your data store. You would NOT prototype the connect function in your subclass, but instead rely solely on your superclass (aka driver API) to provide the connection function signature.
This approach isn't ideal nor the best example of implementing a driver interface, but it is a example of
when to derive from a database class.
2) Core contains your application permissions? Well, ironically I'm writting a auth library as we speak, so I'm quite familiar with how everything should be layed out.
Authentication/Authorization/Sessions
This triad of components are all that is needed to allow access across your site...
Authentication: Is the process of confirming a users validity - checking login credentials against a data store (albeit; XML or MySQL or Flat files, etc).
Authorization: Is the process of granting permission to a authenticated user to carry out an action.
Sessions: The process of expediting re-authentication (so to speak) via a session cookie or authentication ticket if you will (decreases security risk as well - as plaintext passwords aren't send over the wire). This may at first glance seem like part of Authentication, but logically it is a separate entity and should not be integrated with Authentication implementation. They should communicate only through interface.
The process would go something like:
Code: Select all
//
// Sanitization depends on data store for both
// session data and ticket persistance
$ticket_id = $_COOKIE['ticket_id'];
$user_id = is_session_valid($ticket_id); // Return user ID or ZERO on failure
if($user_id){ //
$ret = get_role_value($user_id, 'GROUP_NAME', 'VALUE');
if($ret == TRUE){
echo 'Carry out task';
else
echo 'Incorrect or invalid permission - redirect';
}
else{
echo 'Show login screen as session NOT valid';
}
If this is what
core is attempting to do, I suggest dropping core altogather and calling these classes/functions as demonstrated above as needed in modules like: Language, Log, Template, Setup, etc...
None of those are
"types" of any of the three triad components I mentioned earlier, so derivation isn't really proper OOP practice
Although, I may be wrong here as I don't fully understand the UML diagram you presented, except that like Arborint said,
"it's neat"...
This is strictly a class diagram correct or does it also reflect your file structure, etc???
Cheers
