Re: FW: Bugzilla rewrite in PHP

The DB abstraction layer ships with PHP 4 and gets installed by default. Anybody who has PHP 4 installed has the database abstraction layer installed. In fact all the PEAR modules ship with PHP 4 and get installed by default. An example abstraction script would look like this: require_once 'DB.php'; $db = DB::connect('odbc://user:pw@host/mydb'); $stmt = $db->prepare('SELECT * FROM comments'); $result = $db->execute($stmt); while($row = $db->fetchrow($result)) { foreach( $row as $field => $value ) { echo "$field: $value<br>\n"; } } $db->disconnect(); And as you can see this standard module, along with all the other PEAR modules do give you an OO interface. The only valid criticism I have seen in all this is lack of documentation. The PEAR stuff is documented inline and we have tools to generate external documentation but they have yet to be integrated with the docbook-xml toolset we use for the documentation on the web site. It is underway. -Rasmus On Tue, 21 Nov 2000, Stephen Clouse wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I suppose this will teach me to use that "the following is my very conceited > opinion" header more often. I also must have become confused and accidentally > punched the hole to grant permission to have the post forwarded to > god-knows-where. Either that or I voted for Gore, or something. > > Someone asked for opinions concerning *the Bugzilla project* and I related my > opinions in that context. Why the hell some bonehead felt it was necessary to > carry it over to a PHP advocacy list is beyond me. But I seem to be stuck now. > > > Yes, there are different functions to access different databases. > > This is what, imo, gives PHP it's flexibility. The databases are different, > > and have different functionality, and you should be able to > > access the specific features of each. OTOH, we, as most people, > > have a db abstraction class that handles most of the routine stuff > > for us. nextrow(), query(), open(), close(), etc. Changing databases > > will generally only entail writing new code for those functions, > > and the main code will remain exactly the same. OK, so DBI has > > this predone - PEAR does too, although try to get info on it (or use > > it at an ISP) and you'll have an uphill battle. Once you write it, it's done > > tho. *PORTABLE* to other projects (the seeming opposite of the > > criticism that you're locked into 'code in page' architecture). > > So some people create PHP modules. I wouldn't doubt that. But these things > hide where? Where's the PHP equivalent of CPAN? You can't hardly work with > Perl without knowing what CPAN is, it's discussed in just about every perl > manpage and book. Resources like that should not go very long without being > prominently mentioned. > > But even then, I'd have to say that you're still relegated to the inelegance of > copying that module everywhere you need it, rather than sharing it from a > central module library (at least, there is no language-level facility for this > - -- certainly I could throw something together on my particular machine to > simulate the Perl @INC array, but that would be just my machine). The > inefficiency of the former model should be readily apparent to anyone who has > either Perl or a /usr/lib directory on their system. And this is where the > criticism comes from, everything has to be duplicated, from the library itself > to the line that imports it into every page. > > > True DB *independance* isn't had by Perl DBI. At least, not in my > > experience. > > I *STILL* need to write sql code specific to the database I'm running on. > > If I was connecting to SQL7, I couldn't use 'limit', for example. So how > > much benefit something like DBI gives you over something like PEAR > > or one of the many homegrown solutions is, to me, questionable. > > > > <!--#include (Metabase comments)--> :) > > > > Anyone with more DBI experience care to comment? > > The problems described are the fault of the SQL servers themselves, not DBI or > PHP. I should still be able to code in a way that minimalizes recoding when > I'm ready to port to another database, which DBI does. And assuming that I've > stuck with SQL-92, I CAN take that same program and just change the database > driver parameter, and run it on the new platform. I've done that before, > successfully. Honestly, the differences between the syntaxes of the major SQL > servers, at least in the realm of SELECT/UPDATE/DELETE, are minimal to zero so > long as your schema is properly normalized. And now the consistency of the DBI > interface shows its real benefit. The prepare/execute/fetch model of DBI is > universal, no matter what database I'm using. > > I suppose I'm just lazy (I can hear the replies to this now -- God forbid we > make you write a PHP abstraction layer). But one still wonders why, with all > this database support in PHP, that no one ever considered a standard interface > to be necessary. > > > "PHP's support seems to be quite a bit broader" but he can't tell > > because of the website. Well, how else does it 'seem' broader > > to him? Word of mouth? Higher visibility? > > The documentation spits out a whole list of supported Web servers. One has to > assume that there's broad platform support there as well, but who knows? > Nowhere can I find a list of known working or non-working platforms. > > > The attack on the design of sourceforce is a redherring, obviously. > > "The design of large PHP sites that he sees the code for sucks, > > so PHP must suck." Bugzilla sucks too - that's why people are > > considering the rewrite. "Well, yes, but..." Come on! > > Do you always create broad statements where there are none? Geez, and I even > started out saying "as a [singular] case study", too. > > > "the "script-in-page" concept pretty much defeats > > effective code reuse." Don't put script in a page then. Use > > templates. Easy enough. > > Document what you preach, then. There's only one method I see in the manual. > > > "and each one seemingly has to import about twelve other .php files > > before it can even start to work" > > > > Example Perl script first few lines... > > #!/usr/bin/perl > > use Socket; > > use Net::hostent; > > use CGI qw(:standard); > > use DBI; > > use Net::FTP; > > use LWP::Simple; > > > > Hmmm.... looks like they need to import a lot of files before > > it can even start to work. > > Okay, so I'll admit that point wasn't well thought, and more specific to the > implementation (SF) than the language. But there's something about it that > just makes it "feel" far less clean than importing standard Perl modules. > Perhaps it's simply that Perl *has* standard modules. > > > Sheesh! Could this not be said of CPAN? Not everything in the > > PHP manual is installed by default, but there are ways of putting > > most of that functionality into the PHP interpreter. I wouldn't > > say 'caked-on layers' at all? "obvious lack of direction or > > design" to me is CPAN in a nutshell. I love CPAN and think it's > > great, but there's very little 'direction' there, imo. People > > write modules to solve particular problems and put them > > out for others to use. Same in PHP. > > I don't see how you can look at something like > http://www.perl.com/CPAN-local/modules/00modlist.long.html and > argue that it > has no direction. There seems to be plenty of direction. It's merely an > extremely horizontal market. > > PHP, OTOH, compresses that horizontal market into one monolithic function list. > But that's more from the lack of namespaces than anything. One might consider > that a flaw, too. It's where the seeming lack of organization comes from, > anyway. > > Even setting namespaces aside, you obviously have the OO support (that is > well-documented) -- why aren't you leveraging it as part of the core? Fully > function-based interfaces are painful, particularly to my Perl side. Better > yet, do what CGI.pm does -- offer both with a simple switch. Huzzah. > > > PHP is also easy to maintain as long as you write it that way. > > I didn't say it wasn't. I threw that line out as a repellant toward the > inevtiable comment concerning Perl's syntax, which seems to be some kind of > end-all anti-Perl argument. > > > I almost didn't write, except that, if only for the list archives, > > this kind of 'reasoning' needs to continually be dealt with. I know > > a lot of new people are joining every week and need to be reminded > > that just because someone from 'up on high' says PERL=GOOD, PHP=BAD, > > it's not true. > > Precisely where did the idea come that I'm "up on high"? As if I'm some > kind > of Perl demigod/evangelist. The Perl community at large doesn't even know who > I am. I just program for my company, in whatever language is deemed > convenient. > > PHP has plenty of uses, and I do use it where I find them to be simpler than > Perl. I don't find projects like Bugzilla to be in that category. And as I > said at the top, my "reasoning" was in regards to Bugzilla. In that context, I > like to think I'm right (since I've designed innumerable systems of similar > scope and scale). You act like I set out to slander the Koran. > > But anyway, this is all (like the first time around) just my very conceited > opinion. If you find it flawed, please call someone who cares. With that, I > am done with this discussion (that should have never happened in the first > place). > > - -- > Stephen Clouse <stephenc@theiqgroup.com> > Senior Programmer/Systems and Network Administrator > The IQ Group, Inc. <http://www.theiqgroup.com> > > -----BEGIN PGP SIGNATURE----- > Version: PGP Personal Privacy 6.5.8 > > iQA/AwUBOhso4QOGqGs0PadnEQI9vwCg7kceenYIMUnyYAsU7bOn4VJmA5IAn3jZ > 1QysmBMdJUMIcHIIZ8ZNLyAk > =SzxR > -----END PGP SIGNATURE----- > > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >