Re : proposal rewrite : PHP_Debug

(please ignore the previous email, i sent the email by mistake before it was finished) One year later... :) Sorry this one is a bit long. So my "old proposal" is here : http://pear.php.net/pepr/pepr-proposal-show.php?id=260 Following the advice of Bertrand (at the bottom), it was obvious that a full rewrite was needed. Meanwhile i saw another proposal on Pear that was very near of mine (http://pear.php.net/pepr/pepr-proposal-show.php?id=325) Testing::debugconsole , and it gave me lot of new ideas of the way this package could be coded and improved. By looking both of our proposal, it was obvious that they could be done on the same kernel and we would just have different renderers. The new proposal can be found here : (example with source code) http://www.php-debug.com/tmp/index.php5 1) What is different/corrected/improved from the 1st version ? - It is coded in PHP5 - The design error because of static properties is corrected (connection between the two main classes) - The configuration is simply done with an option array() and there no "one properties by configuration option". - The presentation is completly separated from the code and the factory design is implemented. (My proposal use a HTML_Table renderer) - 2 others renderers will be made, Javascript_Popup in fact it is the renderer used in the other proposal Testing::debugConsole and a Log renderer (with Pear::Log) because i have already several users who asked for it. - The "view source" functionnality is done with Pear::Text_HighLighter - The main function adddebug() doesn't need __FILE__ and __LINE__ arguments anymore, these informations are simply retrieved with the debug_backtrace() PHP function. - The user does not have to handle directly the PHP_DEBUG constant anymore, indeed there are now several seperate function (with simple name) for this purpose example old call : $Dbg->addDebug($arr, DBGLINE_OBJECT, __FILE__, __LINE__, 'object $arr'); new call : $Debug->dump($arr, 'object $arr'); 2) What is is still to do ? - Implement the 2 others renderers Javascript_Popup and Log - Integrate the Pear::Var_Dump for variable dumping - Integrate Pear::SQL_Parser to parse queries. - Some cleaning... 3) I'd need some clarifications on some points : a) The category of the package is PHP, the main classe name is Debug So my constants concerning Debug are prefixed with "PHP_DEBUG_" I have a subclass Debug_Line so the constant concerning this one should be PHP_DEBUG_LINE , right ? (i have to correct it) b) Can i use i a package (Pear::SQL_Parser) that is in devel status ? c) I'd like to give the choice to my users to use Pear or not, so should i maintain 2 packages, one on Pear that will be 100% pear and one other on Sourceforge for the non pear version ? Or should i code this properly directly in the package ? If this is possible what is the best way to do that ? d) In this new version i use an option array, is there a naming convention for the index ? What i have done is that i prefix the index with the class name where it will be used, example : protected $defaultOptions = array( 'DEBUG_render_mode' => 'HTML_Table', // Render mode 'DEBUG_restrict_access' => true ) Does that make sense ? Or should i prefix it with the compete name ? PHP_DEBUG ? Or nothing ? e) For my renderer HTML_Table, i have stored all the html code in a separate config file named HTML_Table_Config, with a simple object with static properties, is this correct way of coding ? The goal is to keep the main class HTML_Table the cleaner possible. Thanks for your feedback and for reading this email until this end. Loïc. :) ------ Pear::PHP_Debug old proposal : http://pear.php.net/pepr/pepr-proposal-show.php?id=260 new : http://www.php-debug.com/tmp/index.php5 ----- Message d'origine ---- De : bertrand Gugger À : Loïc Vernet Cc : pear-dev@lists.php.net Envoyé le : Jeudi, 30 Juin 2005, 12h43mn 25s Objet : Re: [PEAR-DEV] new proposal : PHP_Debug Bonjour loïc, Sorry to answer so late ... True, such a package could be very usefull. You're far from pear cs, but that should not be a problem so long you stay in draft. Some mixed "raw" general remarks : * the pckg optionnally includes a ref to phpmyadmin (only mySql ?), * I did not understood where it was used ... as I saw only the main class. I think that should better be 2 separates files. * I'm very doubtfull about the main connection between main class Debug and class DebugLine built on a global object. I think the class structure could cope with that using references. * also, if I want to debug some classes, the only way I can use is to create a global debug object. Some static method could do it ? * you are mixing the data with the html presentation, I'm not sure it's wide usable for other "outputs" , at least a plain output could be nice. Perhaps some XML or even separate the production and the rendering ? * I've the feeling you intersect with the Benchmark and PHPUnit packages. Some integration could be perhaps envisaged ... * More generally, such system is usefull but necessitates an heavy around coding for each package/class to debug. I'm personnaly orienting (or trying to) Benchmark toward more automatization/tools (see my proposal Benchmark_Resource) . But ok, it's uneasy to define and implement ... er... let me know if my english is too bad, je peux traduire ... à+ bertrand "toggg" Gugger Loïc Vernet wrote: >Hi everyone, > >I have posted a new proposal, it is about debbugging >and i'd like to have some comments about it. > >It is here : > >--> >http://pear.php.net/pepr/pepr-proposal-show.php?id=260 > >