I couldn't help it, I have to respond to that...
I currently debug propel / creole / rapid framework with ntail in eclipse...
in fact, eclipse has two good features it gives you for the 200 megs of ram
it wants to use. A file / directory explorer... and this ntail plugin that lets
you look at ansi (colored) logs... generated by Pear::Log which has been
available since the very beginning in propel... color with ansi where context is needed.,
There is no reason why xdebug can't be used.. in fact... Eclipse's file/directory
manager just launches vim for me on the file... I can then at my leisure hit F5
and rerequest a page on the site... passing of course that /XDEBUG_SESSION_START=
flag... this starts an interactive debugging session inside that vim window... how
that works is a mix of vim scripting and python and is really another discussion.
however, that's a different usage of xdebug but my point is, you can use it or not
use it.. you can also use eclipse or not use it... if whatever diagnostic assertions
can be added to propel with some degree of effeciency then add it but don't dismiss
it out of hand. in fact I like propel / creole php4 better than what's current.... but I don't
try to make everyone use that, even though it's more stable and faster. And works
right in php4 and php5, with other optimizations like 95% of include_once's removed
including other optimizations that are fundamental to opcode caching... why? because
its like putting a gag order on development....
> If you really need the lower level debugging inside Propel then add it
> in a non obtrusive way by enabling dependency injection of classes
> that subclass the default ones but add the debugging functionality and
> then call the parent methods etc.
that's your two cents? I think that's just a buzz word conjugation....
anyway I think refactoring propel into a php extension is the futureproof solution.
and it should be able to use mysql/pgsql extensions on php4 and pdo on php5...
that's an opinion I will support...
On 7/19/07, Christian Kassab <email@example.com> wrote:
why stuff so much debugging functionality into Propel? It is bloated
as it is already. How about using debugging tools like xdebug and
Eclipse? Yes I know you can't look into what goes on inside PDO as in
what the final query string looks like after binding the
variables/parameters, but thats another story...
If you really need the lower level debugging inside Propel then add it
in a non obtrusive way by enabling dependency injection of classes
that subclass the default ones but add the debugging functionality and
then call the parent methods etc.
On 19/07/07, Hans Lellelid <firstname.lastname@example.org> wrote:
> Oliver Schonrock wrote:
> > Cameron Brunner wrote:
> >> Silence is good bad or otherwise?
> > Don't take offense please. I like the features, but I am not sure about
> > the implementation:
> > - using static $query seems untidy
> > - using __destruct() can cause problems depending on your environment
> > - using direct var_dump() it not always suitable.
> > if we are going to add this to the core propel repository, my view would
> > be that it should meet the same criteria as the rest of the code as a
> > generic, high quality toolkit.
> > Part of the reason I focused on simple features was that it is not
> > obvious how to solve some of the above problems with the more advanced
> > features while adhering to the quality standards of the rest of the
> > code. ie can run in any environment, etc..
> > Opinions?
> Without having looked at the code, I second this opinion. We definitely
> don't want to use var_dump, for instance, as this is not particularly
> useful when building webapps that don't return HTML (i.e. that return
> XML/XML-RPC, JSON, etc.).
> My input would be that we need the default PropelPDO to be as
> unencumbered as possible (fast). If we're going to keep all the debug
> stuff in a separate object, then it doesn't matter much how that
> performs. If, however, the aim is to merge this into PropelPDO, then we
> need to make sure that we're doing things in an optimized -- and yes,
> "correct" -- way. We definitely don't want to open the door for subtle
> PHP issues.
> One thing I have learned from using Propel + PDO in PHP
5.2.2 is that
> PDO is not particularly bug-free :) I have dealt with a number of
> segfaults that are directly traceable to PDO. Sometimes it is the
> result of a malformed query (why this segfaults, I have no idea) --- or
> use of PDO streams within user-defined stream wrappers. I *hate*
> debugging segfaults in PHP; what a waste of time. There's apparently
> some really messy stuff under the hood there :) Let's do what we can to
> keep it from rearing its ugly head for users.
> To unsubscribe, e-mail:
> For additional commands, e-mail: email@example.com
+44 (0)789 4467 606
+49 (0)163 6360 939
To unsubscribe, e-mail:
For additional commands, e-mail: firstname.lastname@example.org