On Mon, Oct 11, 2010 at 11:57 AM, Ryan Lange <cl1mh422...@gmail.com> wrote:
> There's no outright conflict, per se, but the expectations of each writer > can create issues when logging objects (at least). Zend_Log_Writer_Firebug > can handle objects, but Zend_Log_Writer_Db, at some point in its execution, > apparently attempts to call the __toString() magic method on objects. > > This causes a couple issues: > > 1) For classes, like Zend_Controller_Request_Http, that don't implement the > __toString() magic method, logging an instance of that class causes > Zend_Log_Writer_Db to throw an exception while Zend_Log_Writer_Firebug will > handle it just fine. > > 2) What if you want to log the structure of, say, an instance of Zend_Form > (for debugging), not the string representation? You could use something like > print_r() and pass the output to the logger to accomodate > Zend_Log_Writer_Db, but then you lose out on the object rendering feature of > Zend_Log_Writer_Firebug. > > Does anyone have any suggestions for working around these issues? > > > Thanks in advance, > Ryan > I thought maybe I'd extend Zend_Log_Writer_Db and modify the _write() method to convert non-string event messages to strings using print_r(), but all of the class properties of Zend_Log_Writer_Db ($_db, $_table, and $_columnMap) are set to private. So, naturally, when my overridden _write() method makes sure that the $_db property is not null, it's denied access and results in an exception informing me that it is null. Bleh... Ryan
