Re: Re: namespaces?
| From: | Erik Hjortsberg | Date: | Sun, 15 Jul 2001 17:22:51 +0000 |
| Subject: | Re: Re: namespaces? | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-798@lists.php.net to get a copy of this message | ||
At 19:27 2001-07-15 +0200, you wrote:
With creating entries it's unlogical to first make an empty object and then issuing it a create message. The logical way is to send a Create message to the class and let it return a new object if successful. Most or all of the pear community agrees with you, the problem is that Zeev doesn't want to make this a feature. There's a thread about it from two months or so back.Hmm, I think you misunderstood me. What I meant was that in my system every table in the database is represented by a class (which is a subclass of a core class; DataObject). These classes are generated through a small webbased-wizard. So if I have a person table I will use the Person class to access it. In order to create a new entry in the person table I use the static method Create in class Person which looks like: <code>
function &Create() {
return parent::Create('Person', array('personCreated' => 'now()'));
}
</code>
This will send a request to the parent class (DataObject) to create a new entry in the person table and in the process set 'personCreated' to now(). If succesful it will then create a new object of type Person, populate it with data from the database, add it to the list of checked out objects and return it. If not successful it will issue a PEAR_Error.
The other way would be to create an empty Person object and then send a create() call to it. But then you would have to handle Person objects that are in limbo, the exisits but have no connection to the database. Plus, if the create statement failed you will still have the Person object, meaning you have to do errorchecking after each create() (if you don't die()), else you'll be using faulty objects. And that's a very bad design.
Whenever you use a DataObject it should always exists in the database too.
The main difference with my system from DB_Storage is that I wanted ways for a programmer to define rules in the dataobjects which would make it easier for other developers and hinder erronous data to be inserted into the database. I can for instance set rules in the Create method.
Say that the table person contains a foreign key ('friendId') wich must be present.
<code>
function &Create($friendId) {
return parent::Create('Person', array('friendId' => $friendId, 'personCreated' => 'now()'));
}
</code>
The wizard also generates functions for accessing all fields, so if I want to set rules for a certain field I can do this.
Or if I want a field to be read-only.
Or if I want to set rules for removing entries from the database I can do this through subclassing the method canDelete() wich is called by the delete() method in the parentclass (DataObject).
The main reason for me to hesitate about submitting it to PEAR is that you have to use the wizard to create the classes. With DB_Storage you can create a standalone DB_Storage object and use it. DataObject on the other hand is an abstract class and _must_ be subclassed to work. The main idea is to access the data through functions, not arrays. And those functions must be generated/written in a certain way.
But if you want I can submit the code.
/erik hjortsberg