Craig Constantine [2007-04-06 12:32 UTC] we use something similar which also allows us to put all the debug/trace output into a file. when we init the tracing objects we tell them where to write. So we can have tracing files per logged in user, per remote IP or whatever we like. When systems go to production we can leave this enabled for a few months having it log to dated directories and such. If any bugs or problems appear in the live product, we can go look at the debug/trace info for the afflicted customer session. Very very useful for forensic analysis.
Loïc Vernet [2007-04-12 08:42 UTC] The 2 existings renderers are mainly to debug "on the fly", but i agree a log feature with a new renderer would be usefull too. Moreover i have several users that already asked me for it in the past. For sure, it will be the next thing i'll do for this package.
Christian Weiske [2007-04-12 10:24 UTC] Nice idea. Here are a few comments:
- __toString needs an uppercase S
- Please put every class in an own file, e.g. PHP_Debug_Line
- Only use private if really needed. Protected methods/variables can be used from inheriting classes.
- Do not use global constants but class constants. This avoids cluttering global namespace
- "class PHP_Debug_Renderer_HTML_Div_Config" is in the wrong file. PEAR CS tell you that underscores need to be replaced with slashes, while you put it into PHP/Debug/Renderer/HTML_Div_Config.php
- If you use visiblity modifiers (public, protected, private), use them everywhere
- "@since 30 march 2007" normally tells you which version, not which date
Loïc Vernet [2007-04-12 21:38 UTC] - __toString methods updated with an uppercase S
- PHP_DebugLine class has now its own file (as all classes now)
- reviewed visiblity modifiers for all methods and attributes
- all global constants switched to class constants
- corrected class naming and directory structure for renderers
- corrected @since doctags
- corrected globally file naming
- package, links & demo updated
[2007-04-14 11:45 UTC] I am not sure how applicable this is here, but since there are
extensions like DBG and xcache and others, would you be able to make
use of those "backends" if they are running/installed/available?
So for example, DBG has a profiler, maybe it would be a good addition
to make your class use DBG's profiling if available.
So I guess I am proposing a general driver-architecture for your
package. Not sure if I am asking too much! ;-)
Loïc Vernet [2007-04-16 11:55 UTC] Till, i agree, i must check how i could retrieve and display debug informations from xdebug, apc, xcache... Indeed it could be nice, i need to investigate on this point. If it could be done, for sure it will be part of a new version.
|
