Re: Re: namespaces?

Erik Hjortsberg wrote: > > 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. Ah, I was talking about the "$this = $obj" trick in the constructor for returning errors with the "new" operator. As for DB_storage that is only one (kinda limited) way of making an object interface to a table. I want to make a list object too, that can represent more than one row. Why don't you post your object so people can look at it? Btw, DB_storage has some validation hooks, but it won't work until I've done a commit :) - Stig