[Fwd: Re: [PEAR-DEV] New package proposal]

Just forwarding to the list in case anyone else is interested... ---8<--- Not rude at all, I appreciate the feedback. Its actually been a while since I used db_dataobjects, so off hand I don't remember ALL the problems I had with it. But I'll throw out what I remember. First, it was harder to setup. I realize there's a learning curve, but I found it unnecessarily complex. I also didn't like the cryptic files that it made. That's fine if everything works fine, but if you find a bug and need to debug it, your don't really have options. -- With mine, you only need to create one file and the setup would be the same as if you wrote the whole thing by hand. Its very easy to follow through. The most you need to look at to get to the bottom of any class is 3 files. Second, when db_dataobject gets updated, the update process is confusing. If you create the getColumn, setColumn variables (and then modify them for your purposes), those will be overwritten when you update the code. -- With mine, the get_column, set_column variables are created by default for all classes and can easily be overloaded: http://www.ddataobjects.com/current/prog/instructions/examples/overloading_functions.php When the code is updated, all custom modifications are saved. Also, you can add comments in the postgresql database to get some advanced features. http://www.ddataobjects.com/current/prog/instructions/setup.php#setter_comment_options Free variable checking for free http://www.ddataobjects.com/current/prog/instructions/examples/db.html <-- see table "person" The default set_ functions will check to make sure a valid zip_code, phone_number, email, and currency are entered. Or you could put your own unique regular expression in. http://www.ddataobjects.com/current/prog/instructions/functions/set_.php (I'll admit this would probably be better in the code, but I didn't think about overloading functions until the was already added) My code also has added functions to make forms much easier to create and parse: http://www.ddataobjects.com/current/prog/instructions/functions/get_ie.php Also, I create the option of linking tables. Let's say you have two tables person - person_id, name, address, ... pics - pics_id, person_id, size, file, ... If you create the foreign key in pics to point to person, then when you delete person "person->delete()" it knows the tables are linked and will automatically delete the corresponding pics. There are quite a few other additions over db_dataobject, but at this point I'm guessing you've made up your mind whether or not you think this is worth the trouble. So I'll stop here. You don't have to go into great detail to checkout the code, just click on a couple functions and look at the example code to see how concise this enables you to code. I've highlighted what I think some of the better features are. As the only person that responded, I'll let you decide what to do with this. If you think it could be of benefit to the community, I'll pursue it. If not, I'll just keep working on it for myself and using it for myself. I think I've made a VERY useful product and was interested in giving back to the community, but if everyone is happy with what they have, its not a problem. Thanks for responding (and making it in this email if you did), Dan On Feb 7, 2008 8:41 PM, David Sanders <dsanders@baselinesolutions.com.au <mailto:dsanders@baselinesolutions.com.au>> wrote:

    Dan Hayes wrote:

I wrote code that is somewhat similar to db_dataobjects, but in

    my opinion,

offers numerous advantages over db_dataobjects. It currently

    only works for

postgresql (I don't think it wouldn't be that difficult to make

    it work with

mysql also), but I've documented it, and there are lots of

    options.  Its

also very easy to get up and running and to update and modify.

     I'm not sure

if this would be a good PEAR package, or if I should just continue developing it as is. Any feedback would be appreciated. http://www.ddataobjects.com

    I don't mean to be rude here but I think you need more than just a vague
    paragraph explaining why you don't want to use MDB2...  Nor have you
    even
    bothered to explain what the improvements over DB_DataObject are.
     To be frank,
    I don't think you'll get many people wasting their time sifting
    through your
    code to see if it'll be worth anything.

    --
        David Sanders
        shangxiao