Jenk

class Foo private $bar public function __construct ($bar = 'foo') { $this->bar = $bar; //proceed to use $this->bar. } }

Don't use the global keyword. Depending on the frequency of use, either pass the instantiated mysql class object to the constructor, or to an injector later.

Database accessors should not be singleton. Why? Multiple user sessions will need multiple connections; else you will find your applications will have (database) session collisions. EDIT: Infact, you can ignore this post. I'd forgotten PHP is not state persistent so the above does not apply.

I appreciate others use them and that it helps them, debatable if they are for good measure though. I'd much prefer to see those same people knocking up code than spending time making diagrams. (Which is opinion - as is everything you'll see on any forum) There was an article I read somewhere that phrases this much better than I ever could, but I can't find it at the moment. The point about porting is not a very strong one - if you have found yourself needing to change platform like that, you've made a poor decision (of which platform to use) in the first place. Personally I gain far more from reading/creating Test Cases (not just Unit Tests) than I do from connecting boxes with labels.

Matter of preference, but in the time it takes to create a UML diagram, my test cases are complete.

Criticism: check() should return boolean. setName() is not necessary when all you are doing is assign whatever value is sent to it. No type checking, no value validating, no nothing.

Less planning, more doing. UML diagrams are pretty, but they don't do anything. Code does.

Tried using register_shutdown_function()?

You can't throw exceptions/instantiate new objects within a __destruct(). It is aimed at literally clean ups only, not processing or application flow.

have the constructor set to private, or if you are still using the stone age php4, trigger_error(). <?php class Foo { private function __construct () {} // prevents object instantiation } ?>

First rule of OO.. don't reinvent the wheel. There are literally thousand's of CMS applications to choose from. That aside, you are looking at your class structure wrong. Classes (and thus objects) are there as objects of behaviour. You would hae one class for database accessing, another possibly for the result sets returned, and so forth. Not "one for this table, one for that table, etc." You can use a TableDataGateway (see Design Patterns) object, which you can use, but it is not explicity a "Table of data" it is simply, as the name suggests, a gateway for fetching data from that table - it will have a child consisting of the DataSource accessor (object)

child constructors do not call upon parent constructors unless you explicitly call them with the parent keyword.

Just don't insert a value. If the field is an auto-incremental field, the database will automatically assign the next increment for you. You can then fetch that number with mysql_insert_id();

You need to read up on simple syntax, and also need to take note that "or die" is not the keyword, "or" is the keyword. <?php mysql_connect($host, $user, $pass) or header('Location: http://host/somepage.php'); ?>

no, you do not do that. You create an array of checkbox values. <?php foreach ($records as $record) { echo "<input type=\"checkbox\" value=\"{$record['id']}\" name=\"check[]\"/>\n"; } ?> Then on the receiving page, you traverse the array: <?php foreach ($_POST['check'] as $checkbox) { delete_record($checkbox); } ?> after sufficient validation.

Lose the die's, your data source layer should not be directly outputting. Use exceptions to raise issues to the parent layers, so they can handle them appropriately for the circumstance.

$_SERVER['REQUEST_URI'] or $_SERVER['QUERY_STRING']

You haven't defined $var. Read people's replies carefully, this was answered in the first reply.

you haven't defined changedProperties, and you are setting Properties, not properties (note the uppercase P)

Zend PDT plugin for eclipse. It's free. www.zend.com/pdt

You can "helllllllllllllllllllllllllllllllllllllllllp" us, by firstly removing whatever it is that is sticking your 'l' key down, then by posting any code you have already started with.

You are all missing the point entirely. 200 objects is far too much. Redesign your application.

shell_exec()

What on gods green Earth requires "more than 50 classes" and "over 200 instances of them" for every page view?

They are ultimately more difficult to maintain, and require heavy interaction from a source controller to ensure that code is kept in relevant groups. Masses upon masses of documentation are needed for projects like Linux Kernel; variable names, references, etc. Not need in OOD due to interfacing and so forth. Most of the time you don't even need to know the class name of your object, only what interface it has. This cannot be done in Procedural; so there is precisely no polymorphism - you must explicitly know what, where and when your resources are going to be available, and must know not only what your resources are, but also what the name of the variable containing those resources are. Not so in OOD.