Advice on a 'bigger' site. PEAR opinions?

[mwmitchell]

I'm re-building a website that is pretty large in that it has members, member "storefronts" all kinds of categories that change dynamically, an admin front-end, etc...

The site is built from PEAR:B and Smarty now. I didn't want to re-build it using PEAR, or Smarty but...

I started messing around with PEAR DB_DataObject tonight and I'm blown away at how easy it is to access "entities" now. It's so easy that it doesn't matter to me if the PEAR code is what some people call "bloated". This is going to make my life so much easier.

I'm wondering if anyone has any experience with any of the following classes:

DB
DB_DataObject
HTML_QuickForm
HTTP_Upload
DB_Pager
Mail

Pros/Cons? I know there are a lot of tutorials out there, but I want some real feedback.

I've actually always been oppossed to using large, open-source libraries (because it's so much more fun for me to code), but if these packages are *stable*, that's all that matters.

Thanks!

Matt

[astericks]

I just thought I'd toss in another question:

Does the pearDB package have any edge of the eclipse package by Vincent?

[Phil.Roberts]

I just thought I'd toss in another question:

Does the pearDB package have any edge of the eclipse package by Vincent?

Only in terms of extended functionality.... But simplicity goes straight out the window.

[prefab]

I'm wondering if anyone has any experience with any of the following classes:

DB
DB_DataObject
HTML_QuickForm
HTTP_Upload
DB_Pager
Mail

Hi,

I see you found your way to DB_DataObject too that package alone made me consider PEAR too.
Now I'm working on my own PEAR based framework (actually, the framework itself is based on Ismo,
ismo.sf.net, while most of the added functionality stems from PEAR based work).

I even got involved in a couple of projects myself. If you like DB_DataObject, I can recommend DB_DataObject_Formbuilder which can create QuickForm forms form your DBDO.
You can customize the form in any way you like. So I would recommend QuickForm too.

To me the talks about the PEAR bloat seem to originate from complete ignorence. Plus, even if they were really,
bloated (they're not!!), the added value and convenience that help to create apps faster, far outweights that.
Besides, servers get faster everyday, so it's easy to compensate if needed. Hardware is cheaper
than development time IMHO.

Why is it that PEAR always gets so much bad press on these boards? There are lots of efficient and usefull packages in PEAR, good quality stuff really. Most of the packages submitted nowadays are worth their salt IMHO.

- prefab

[lastcraft]

Hi...

I see you found your way to DB_DataObject too that package alone made me consider PEAR too.

It is a really easy class to implement yourself, so you are not tied to PEAR.

Why is it that PEAR always gets so much bad press on these boards?

I have personally had so much grief at various times I have almost given up on it. The error handling mechanism sucks and I have run into far too many bugs and out of date documentation. The library is also very difficult to extend, because of the large monolithic classes and lack of tests. I have to weigh evaluating using a library against writing things myself. On that basis PEAR stuff seems to take longer. Now this is a personal opinion and I could have been unlucky. The biggest disasters I have had (some time ago now, so issues may have been fixed) have been with SOAP and DB_DataObject .

I guess it depends on whether you have been burned.

yours, Marcus

[ghurtado]

I have to agree with Marcus that one of the biggest problems PEAR has is error handling. AFAIK, its implemented by methods returning an "error object" as oppossed to "False" when they fail. Given that PHP provides you with very customizable error handling hooks, this is not only unnecesary, but completely contrary to many coding guidelines I have heard over the years. As much as I can, I always try to return false from a method that fails or throws an error.

[mwmitchell]

I even got involved in a couple of projects myself. If you like DB_DataObject, I can recommend DB_DataObject_Formbuilder which can create QuickForm forms form your DBDO.
You can customize the form in any way you like. So I would recommend QuickForm too.

Yes, i heard about DB_DataObject_Formbuilder and would like to check it out! Some times it's just nice when you can get the job finished fast, and th'at why these tools are sounding so good to me right now.

Hi...
It is a really easy class to implement yourself, so you are not tied to PEAR.

Marcus,

How do you mean implement myself? You mean seperate the package from the PEAR library, or write my own DataObject class/library? If you are talking about my own, could you maybe give me a few tips in the right direction? I've been using the MyDatabase from Eclipse for a long time, and haven't had any problems.

Anyone want to write out an example of a DAO/DataObject class using Eclipse Database? - would just love to see it! I have tried, and could post some examples of what I've done.

Thanks for all of the feedback!

Matt

[lastcraft]

Hi...

Marcus,

How do you mean implement myself?

I am nowhere near my home machine right now. When I get back in a couple of days I'll post some code. It was actually the first class I ever wrote in PHP, so I'll probably cheat and tidy it up as well .

yours, Marcus

[mwmitchell]

Hi...



I am nowhere near my home machine right now. When I get back in a couple of days I'll post some code. It was actually the first class I ever wrote in PHP, so I'll probably cheat and tidy it up as well .

yours, Marcus

Allright! I look forward to your post, and thanks again!

Matt

[Phil.Roberts]

Anyone want to write out an example of a DAO/DataObject class using Eclipse Database? - would just love to see it! I have tried, and could post some examples of what I've done.

This is probably how I would do it:

<?php

include_once(APP_ROOT . 'eclipse/MyDatabase.php');

class DAO {
    var $dbConn;
    function DAO() {
        $this->dbConnect();    
    }
    
    function dbConnect() {
        $this->dbConn =& new MyDatabase('news_db', 'localhost');
        if(!$this->dbConn->connect('username', 'password')) {
            trigger_error('Unable to establish database connection.<br /> 
                           Error returned from MySQL: ' . $this->dbConn->getErrorMessage());
        }
    }
}

class NewsDAO extends DAO {
    function NewsDAO() {
        parent::DAO();
    }
    
    function &getAllHeadlines($offset = 0, $limit) {
        include_once(APP_ROOT . 'eclipse/PagedQuery.php');
        $query =& new PagedQuery(
            $this->dbConn->query('SELECT * FROM news ORDER BY article_id DESC'), $limit
        );
        if(!$query->isSuccess()) {
            trigger_error('Error while retrieving headlines.<br />$
                           Error message returned from MySQL: ' . $query->getErrorMessage())
        }

        include_once(APP_ROOT . 'eclipse/QueryIterator.php');
        $page = $query->getPage($offset);
        return new QueryIterator($page);
    }
    
    function getArticleById($id) {
        $query =& $this->dbConn->query('SELECT * FROM news WHERE article_id=' . $id);
        if(!$query->isSuccess()) {
            trigger_error('Error while retrieving article.<br />
                           Error message returned from MySQL: ' . $query->getErrorMessage());
        }
        return $query->getRow(0);
    }
}


?>

[sweatje]

Off Topic:

...
It was actually the first class I ever wrote in PHP, so I'll probably cheat and tidy it up as well .

Perhaps that would be an interesting thread: My first PHP class ( From the grizzled OO verterans at least )

[mwmitchell]

Phil,

Interesting... I see that you return the QueryIterator, and not an array. Is there a reason you do this?

Matt

[Phil.Roberts]

Phil,

Interesting... I see that you return the QueryIterator, and not an array. Is there a reason you do this?

Matt

Becasue NewsDAO::getAllHeadlines() would return multiple rows. And loading them into an array would be pretty inefficient. Better to just return the iterator object which I would only be using on the resultset anyway.

[coo_t2]

I've been using HTML_Form, and the Tree package, and some other libraries that depend on PEAR, like patUser.
I've never really used PEAR in the past, but I'm sure I'll be using it a lot more in the future. I may even contribute something to it.

As far as PEAR being bloated, I don't think this is really a big issue unless you plan on distributing your app. Because if your site is important enough that you are worried about performance, surely you will choose a host that has something like the Zend Accelerator installed(Or install something similar yourself if you're running your own machine).


--ed

[YCrowley]

This is probably how I would do it:

A little late with a reply here, and probably an idiotic question (only just getting into OOP), how would you echo onto you page for example, $query->getRow(0);

?

ta in advance

[mwmitchell]

Hi...
I am nowhere near my home machine right now. When I get back in a couple of days I'll post some code. It was actually the first class I ever wrote in PHP, so I'll probably cheat and tidy it up as well .

yours, Marcus

Marcus,

Are you still open to posting some code? I know you're probably busy, just thought I'd let you know that I'm still very interested!

Thanks,

Matt

[lastcraft]

Hi...

Are you still open to posting some code? I know you're probably busy, just thought I'd let you know that I'm still very interested!

Sorry, sorry, sorry . Completely forgot. I'll dig it out tomorrow. It won't have been worth the wait...

yours, Marcus

[Phil.Roberts]

A little late with a reply here, and probably an idiotic question (only just getting into OOP), how would you echo onto you page for example, $query->getRow(0);

?

ta in advance

$article = $dao->getArticleById(2);

echo $article['headline'];
echo $article['story']; 

[lacerus]

$article = $dao->getArticleById(2);

echo $article['headline'];
echo $article['story']; 

$article is not supposed to be an array. That's what a simple DB abstraction object would return. It is supposed to be an article object that has methods. Read a lot on DAOs and OOP. It takes a while to grasp, but then it's a whole lot of fun. Get Martin Fowlers book, too. Whatever you post here - at least one person will tell you to get it. And they are right.

[Phil.Roberts]

$article is not supposed to be an array. That's what a simple DB abstraction object would return. It is supposed to be an article object that has methods. Read a lot on DAOs and OOP. It takes a while to grasp, but then it's a whole lot of fun. Get Martin Fowlers book, too. Whatever you post here - at least one person will tell you to get it. And they are right.

What the hell for? It's a method that returns a single news article. Why would I need it to return any objects at all? I do that with the getAllHeadlines() method, which returns an iterator object.

It's all totally moot anyway as I wrote that example off the top of my head. It doesn't actually get used anywhere.

[been]

What the hell for? It's a method that returns a single news article. Why would I need it to return any objects at all? I do that with the getAllHeadlines() method, which returns an iterator object.

I think the main reason for returning an article object would be abstraction of the column names in the database.
Suppose you wrote a nice db-abstraction layer, implemented DAO's, etc... and all of a sudden, the column names of the articles' db table get changed for whatever reason, then you'd still have to change code in the 'other layer' because the column names are reflected in the keys of the array...

[lastcraft]

Hi...

Are you still open to posting some code? I know you're probably busy, just thought I'd let you know that I'm still very interested!

Ok you asked for it . Was it really three years ago (sigh)?

Things I have changed since:

1) No more hungarian notation. I wasn't into unit testing at the time and so any notation (comments, naming conventions) that would catch errors were employed. The unit testing has made these things redundent.
2) The class is too big. There is some MySQL set manipulation stuff
3) I no longer do logging unless it is an application requirement. Sifting log files is a pretty thankless way to debug. Again testing has made this unnecessary.
4) Methods are too long and "clever".
5) I now use Java naming conventions just because everybody else does.
6) I wouldn't have a class called "Factory" anything. That's implementation not interface.
7) I now use PHP4.

If you strip out all of the logging, comments and unused code it would probably shrink by a factor of three.

It's an abstract RowDataGateway in Fowler speak.

yours, Marcus

[Taoism]

AFAIK, its implemented by methods returning an "error object" as oppossed to "False" when they fail. Given that PHP provides you with very customizable error handling hooks, this is not only unnecesary, but completely contrary to many coding guidelines I have heard over the years. As much as I can, I always try to return false from a method that fails or throws an error.

Late to the thread, but I disagree with you on this. We use an error object to return errors in our code because it guarantees that the result is an error. You can say, "return a false for errors" until you run into a situation where a false is a valid result, and then you begin to code by exception.

"False means error except in this case where null means error". What happens when both null and false are acceptable? Then -1 means error? Etc...

An error object prevents this... if an error object is returned, there is no doubt that an error is the result.

Just my belated $0.02!

Cheers,
Keith.

[ghurtado]

Perhaps throwable exceptions in PHP 5 will solve both your concerns about how to define an error and mine about mantaining error handler independance?

[HarryF]

Late as well - on those packages;

DB - is very solid. The code could be better optimized but it does what it says on the label - DB gets heavy use and is great when you want to "step into" a database you don't know so well.

DB_DataObject - like some of the principles. The generated code you probably need to subclass with your own class so you have "fixed api" for the rest of your app. It may be I was using it wrong but I found handling table relationships cumbersome via the DB_DataObject API but otherwise it's useful to shortcut the time spent on writing (testing) hand coded SQL. Code seems a little monolithic last time I looked - lot of code in one file - might benefit from breaking it up.

HTML_QuickForm - great for a quick solution (e.g. a single page that needs a solid form) - very powerful in fact and does alot to keep you secure. Last time I tried passing an instance of quickform to another object though, things went badly wrong - seems to rely on access to globals or something - that kind reduces the sphere to which QuickForm can be used for.

HTTP_Upload, DB_Pager, Mail - no idea.

Overall, quality in PEAR varies - there's some great stuff and some that needs work. Really we should submit refactorings to the developers - in many cases it should be well received. Also if the lead developer has gone quiet, you may be able to take over running a PEAR package.

PEAR packages in general save you development time but may cost you later - really you need is to research in spare time and find what you like - that means reading source code.

Also most PEAR code is not designed for performance (today). E.g. 90% start with;

require_once 'PEAR.php'; 

That one line adds about 1000 lines of code for PHP to parse.

Overall I've grown to like PEAR but in some cases, it does need work. Best is to get involved and see if you can change things. The current leaders of PEAR are aware of the weaknesses and open to suggestions for improvment (or better yet offers to help with coding).