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

Not harsh at all, I appreciate the feedback. I disagree with some of your comments, but that's the beauty of open-source. When I disagree, I can go my own route. It doesn't appear anybody sees my code as useful, so I'll just use it for my own projects. Thanks for the feedback. On Feb 11, 2008 2:00 AM, Alan Knowles <alan@akbkhome.com> wrote: > David Sanders wrote: > > 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. > Sounds a bit surprising, - there are quite a few tutorials (other than > the manual), quite easily found via google. pear-general or the irc > channels can be useful as well. > DB_DataObject::debugLevel() is a good clue for debugging.. > > -- 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. > It's quite easy to make a simpler version, but DB_DataObjects is quite > well maintained, although it's release schedule could do with > improving.. What you have is what DB_DataObjects was similar to over 6 > years ago - It's grown alot since then (for better and worse..), and > there is already a maintained alternative, DB_Table in PEAR. > > At the end of the day, if you converted it to PEAR standards, you would > end up with something very close to what DB_DataObject already is. > > > > > Second, when db_dataobject gets updated, the update process is > > confusing. > Care to elaborate - it should be relatively obvious. > > If you create the getColumn, setColumn variables (and then > > modify them for your purposes), those will be overwritten when you > > update the code. > This should not happen - although there may have been bugs in some > versions that caused that occasionally. > > -- 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. > This can already be done, generate_setters/generate_getters options > (although I never personally use them) > > > > 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 > > > This does seem a bit magical, although I dont think it would be > particularly difficult to add to DB_DataObject. > > > > Free variable checking for free > > > > http://www.ddataobjects.com/current/prog/instructions/examples/db.html > This could be added to DB_DataObject although I suspect stored > procedures are probably the best way to do this. > > <-- 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 > > > This kind of violates the separation of logic and presentation. - but > not particularly difficult to do in DB_DataObject. > > > > 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. > probably best done using TRIGGERS in the database, I tend to find doing > all of this automatically can result in some unexpected issues.. - > > > > 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. > If it was PDO based, PHP5 only and clean, followed PEAR standards, had > multiple database support etc. and followed a similar model to DB_Table > or DB_DataObjects you might have a fighting chance, but I dont think > this is really an advancement on where the D.O. abstraction layers are > in PEAR at present. > > You have come up with few 'cool' ideas - running from a url etc. that > really need to be thought through as well - On the face of things it > appears to be considerably more complex to understand than DB_DataObject > is. - let alone debug... > > I would recommend even if you just want to share this and use it for > your own projects, that you consider following PEAR standards, and move > away from in-line scripting style. > > I hope the comments where not to harsh > > Regards > Alan > > > > 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 > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >