Re: Re: namespaces?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would personally LOVE to see this submitted or at least available for download!!! - -- Jeff Stuart jstuart@neo.rr.com "Erik Hjortsberg" <azatoth@hem.passagen.se> wrote in message news:5.0.2.1.0.20010715184740.00a9dce0@pop.student.lu.se... > 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO1InTo2gaWDOuGieEQJMBACfc23Om08DrhXuc8imwxjXnoNXsjYAmgPU esn9bQ4WUcf9/2EJdUk03MDJ =JVzt -----END PGP SIGNATURE-----