Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » var_dump_html() »

var_dump_html()

php.internals

Marco Tabini

23 years ago
Not sure if this interest anyone, but the attached patch adds a function called var_dump_html() that performs the same functionality as var_dump(), except that it outputs HTML instead of plain text. var_dump() is a bit impractical to use in a web environment, IMO. Cheers, Marco
-- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca

Derick Rethans

23 years ago
On Thu, 3 Jul 2003, Marco Tabini wrote:
> Not sure if this interest anyone, but the attached patch adds a function > called var_dump_html() that performs the same functionality as > var_dump(), except that it outputs HTML instead of plain text. > var_dump() is a bit impractical to use in a web environment, IMO.
We already have three functions for dumping debug info (var_dump, var_export and print_r). The latter two can be used like: echo "<pre>". var_export($var, TRUE). "</pre>"; I don't think that we should add another here. regards, Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Ken Tossell

23 years ago
Quoting Derick Rethans <derick@php.net>:
> On Thu, 3 Jul 2003, Marco Tabini wrote: > > > Not sure if this interest anyone, but the attached patch adds a function > > called var_dump_html() that performs the same functionality as > > var_dump(), except that it outputs HTML instead of plain text. > > var_dump() is a bit impractical to use in a web environment, IMO. > > We already have three functions for dumping debug info (var_dump, > var_export and print_r). The latter two can be used like: > > echo "<pre>". var_export($var, TRUE). "</pre>"; > > I don't think that we should add another here.
I'm with you on this, specifically, but I'd like to see a dump function that can do coloring. :-)
> > regards, > Derick > > -- > "Interpreting what the GPL actually means is a job best left to those > that read the future by examining animal entrails." > ------------------------------------------------------------------------- > Derick Rethans http://derickrethans.nl/ > International PHP Magazine http://php-mag.net/ > ------------------------------------------------------------------------- > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Ken Tossell ken at tossell dot net http://www.kennyt.com/ washington, dc / gmt-4 world::free.capital();

Marco Tabini

23 years ago
My only consideration is that most people use var_dump in a web environment--hence it seems counterintuitive to have to enclose the function in additional HTML tags. Cheers! On Thu, 2003-07-03 at 11:09, Derick Rethans wrote:
> On Thu, 3 Jul 2003, Marco Tabini wrote: > > > Not sure if this interest anyone, but the attached patch adds a function > > called var_dump_html() that performs the same functionality as > > var_dump(), except that it outputs HTML instead of plain text. > > var_dump() is a bit impractical to use in a web environment, IMO. > > We already have three functions for dumping debug info (var_dump, > var_export and print_r). The latter two can be used like: > > echo "<pre>". var_export($var, TRUE). "</pre>"; > > I don't think that we should add another here. > > regards, > Derick
-- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca

epplestun

23 years ago
In my opinion is good idea but Derick has rason, is better if var_dump_html colorise the output :-) ----- Original Message ----- From: "Marco Tabini" <marcot@tabini.ca> To: "Derick Rethans" <derick@php.net> Cc: <internals@lists.php.net> Sent: Thursday, July 03, 2003 5:13 PM Subject: Re: [PHP-DEV] var_dump_html()
> My only consideration is that most people use var_dump in a web > environment--hence it seems counterintuitive to have to enclose the > function in additional HTML tags. > > Cheers! > > On Thu, 2003-07-03 at 11:09, Derick Rethans wrote: > > On Thu, 3 Jul 2003, Marco Tabini wrote: > > > > > Not sure if this interest anyone, but the attached patch adds a
function

Vlad Bosinceanu

23 years ago
What could it possibly colorize and how would it be useful? epplestun wrote:

Frank Wiegand

23 years ago
Marco Tabini wrote:
> Not sure if this interest anyone, but the attached patch adds a function > called var_dump_html() that performs the same functionality as > var_dump(), except that it outputs HTML instead of plain text. > var_dump() is a bit impractical to use in a web environment, IMO.
Please have a look at PEAR::PHP::Var_Dump: http://pear.php.net/package-info.php?pacid=103 Frank

Marco Tabini

23 years ago
On Thu, 2003-07-03 at 11:47, Frank Wiegand wrote:
> Marco Tabini wrote: > > > Not sure if this interest anyone, but the attached patch adds a function > > called var_dump_html() that performs the same functionality as > > var_dump(), except that it outputs HTML instead of plain text. > > var_dump() is a bit impractical to use in a web environment, IMO. > > Please have a look at PEAR::PHP::Var_Dump: > > http://pear.php.net/package-info.php?pacid=103
Thanks, Frank, I have. But do I really want to load up a PEAR class to dump my variables to the browser? For me, the answer is no--although, obviously, that is only my opinion. Cheers, Marco
> > > Frank
-- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca

Frank Wiegand

23 years ago
Marco Tabini wrote:
>> Please have a look at PEAR::PHP::Var_Dump: >> http://pear.php.net/package-info.php?pacid=103 > Thanks, Frank, I have. But do I really want to load up a PEAR class to > dump my variables to the browser? For me, the answer is no--although, > obviously, that is only my opinion.
IMHO its not PHP's job to produce HTML output for debugging purposes. I'd prefer the PEAR package, because: * You have more control about the output layout (Var_Dump.php uses skins). * There are (as said) three functions in PHP that do nearly all the same. * Using the package is not more complicated than using var_dump. It's a two liner (but you can use auto_prepend_file). Using Var_Dump makes your script slower, but (high-)speed doesn't matter while debugging PHP scripts. Frank

Marco Tabini

23 years ago
On Thu, 2003-07-03 at 13:09, Frank Wiegand wrote:
> IMHO its not PHP's job to produce HTML output for debugging purposes.
Well, then, I guess we'll have to agree to disagree. IMO, PHP's job is to work in a way that is most useful to the developer. Since most developers use PHP in web projects, it makes sense, I think, that PHP's debug output is suitable to that environment.
> > I'd prefer the PEAR package, because: > > * You have more control about the output layout (Var_Dump.php uses skins). > * There are (as said) three functions in PHP that do nearly all the same. > * Using the package is not more complicated than using var_dump. > It's a two liner (but you can use auto_prepend_file).
A two-liner is twice as many lines as a one-liner :-) . In a debugging situation, you often add and remove var_dump()'s quickly and all over the place while hunting down a bug. Having to worry about an extra step uselessly complicates things, in my view. If using the built-in functions is not any more complicated than using PEAR, then why not get rid of them at all? Because they are useful, of course. Except that in their current form they are less useful than they could be.
> Using Var_Dump makes your script slower, but (high-)speed doesn't matter > while debugging PHP scripts.
Agreed. But high development speed does matter, and having to use PEAR doesn't help you there. In any case, the discussion is sort of moot, since the patch won't be applied. I'll just use it for my internal purposes, and it's in the archives for anyone who may find it useful. Cheers, Marco
-- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca

Frank Wiegand

23 years ago
Marco Tabini schrieb:
> A two-liner is twice as many lines as a one-liner :-) .
Thats why I pointed to auto_prepend_file.
> In a debugging > situation, you often add and remove var_dump()'s quickly and all over > the place while hunting down a bug. Having to worry about an extra step > uselessly complicates things, in my view.
Yes. But that's only one way of debugging.
> If using the built-in functions is not any more complicated than using > PEAR, then why not get rid of them at all? Because they are useful, of > course. Except that in their current form they are less useful than they > could be.
Right. var_dump in HTML is a pain. But IMO PHP should provide only a core of functions. Functions for the basic use of the *language*. You can put anything into PHP itself, but this makes PHP bigger and fatter. $ ls -l `which php` | awk '{ print $5; }' 4009419 (That's the biggest binary on my machine, btw.) Yes, your patch adds only a few lines ...
>> Using Var_Dump makes your script slower, but (high-)speed doesn't matter >> while debugging PHP scripts. > Agreed. But high development speed does matter, and having to use PEAR > doesn't help you there.
PHP is not (yet?) designed to do good PHP script debugging.
> In any case, the discussion is sort of moot, since the patch won't be > applied.
I'm just a user of PHP, I don't have to decide that.
> I'll just use it for my internal purposes, and it's in the > archives for anyone who may find it useful.
There is also a PECL package for debugging purposes: http://pear.php.net/package-info.php?pacid=214 Frank

Björn Schotte

23 years ago
* Marco Tabini wrote:
> Thanks, Frank, I have. But do I really want to load up a PEAR class to > dump my variables to the browser? For me, the answer is no--although, > obviously, that is only my opinion.
Normally one would dump to an error_log (and having a tail -f php_error.log in another shell), not to the browser. If one has a small web package, he could do "<pre>" ... "</pre>", so there shouldn't be any problem.
-- ThinkPHP und Partner auf dem LinuxTag. Seien Sie mit dabei, und lernen Sie die PHP Profis kennen! 10. - 13. Juli 2003, Karlsruhe. * ThinkPHP sponsert "PHP and friends"-Projekt auf dem LinuxTag *

Marco Tabini

23 years ago
On Thu, 2003-07-03 at 13:33, Björn Schotte wrote:
> Normally one would dump to an error_log (and having > a tail -f php_error.log in another shell), not to the browser. > If one has a small web package, he could do "<pre>" ... "</pre>", > so there shouldn't be any problem.
Yes, but-- (a) Not everybody does it that way (b) Not everybody *can do it* that way--think Windows users. Cheers, Marco
-- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca

Björn Schotte

23 years ago
* Marco Tabini wrote:
> (a) Not everybody does it that way
That's no argument.
> (b) Not everybody *can do it* that way--think Windows users.
Cygwin exists and I'm sure there's a bunch of freeware/shareware tools that do the same.
-- ThinkPHP und Partner auf dem LinuxTag. Seien Sie mit dabei, und lernen Sie die PHP Profis kennen! 10. - 13. Juli 2003, Karlsruhe. * ThinkPHP sponsert "PHP and friends"-Projekt auf dem LinuxTag *

Marco Tabini

23 years ago
On Thu, 2003-07-03 at 13:43, Björn Schotte wrote:
> * Marco Tabini wrote: > > (a) Not everybody does it that way > > That's no argument.
Well, how can I argue with this? <g>
> > (b) Not everybody *can do it* that way--think Windows users. > > Cygwin exists and I'm sure there's a bunch of freeware/shareware > tools that do the same.
So, your position is that a developer should bend to the technology. Mine is that the technology should bend to the developer. Both have their merits. I'll use my patch and you can use your error log--nothing wrong in either case. Marco
-- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca

Björn Schotte

23 years ago
* Marco Tabini wrote:
> So, your position is that a developer should bend to the technology.
No. My position is that a developer should evolve and learn that there are some more professional ways than just dumping debug data to the browser instead of a log file.
-- ThinkPHP und Partner auf dem LinuxTag. Seien Sie mit dabei, und lernen Sie die PHP Profis kennen! 10. - 13. Juli 2003, Karlsruhe. * ThinkPHP sponsert "PHP and friends"-Projekt auf dem LinuxTag *

Marco Tabini

23 years ago
On Thu, 2003-07-03 at 13:49, Björn Schotte wrote:
> * Marco Tabini wrote: > > So, your position is that a developer should bend to the technology. > > No. My position is that a developer should evolve and learn > that there are some more professional ways than just dumping > debug data to the browser instead of a log file.
Please, do not imply that what I am suggesting is unprofessional. It is practical. It works just as well, and is applicable to a wider range of platforms than your methodology without requiring any special setup.
> > -- > ThinkPHP und Partner auf dem LinuxTag. Seien Sie mit dabei, und > lernen Sie die PHP Profis kennen! 10. - 13. Juli 2003, Karlsruhe. > > * ThinkPHP sponsert "PHP and friends"-Projekt auf dem LinuxTag *
-- Marco Tabini President Marco Tabini & Associates, Inc. 28 Bombay Avenue Toronto, ON M3H 1B7 Canada Phone: (416) 630-6202 Fax: (416) 630-5057 Web: http://www.tabini.ca

Björn Schotte

23 years ago
* Marco Tabini wrote:
> On Thu, 2003-07-03 at 13:49, Björn Schotte wrote: > > No. My position is that a developer should evolve and learn > > that there are some more professional ways than just dumping > > debug data to the browser instead of a log file. > Please, do not imply that what I am suggesting is unprofessional.
I didn't say that nor did I imply it. I only said that in the time of being a PHP developer one will change from browser output to logfile output.
> It is > practical. It works just as well, and is applicable to a wider range of > platforms than your methodology without requiring any special setup.
If so, then I would suggest the following add-ons: - var_dump_pdf (majority of all PCs/browsers have PDF plugin, imagine nice formatted or coloured var_dumps in a portable document) - var_dump_swf (fast and slim, >90% of browsers do have flash technology) - Silicon Graphics data explorer, true virtual reality with a dataglove, especially useful with thousands of array elements SCNR, Björn.
-- ThinkPHP und Partner auf dem LinuxTag. Seien Sie mit dabei, und lernen Sie die PHP Profis kennen! 10. - 13. Juli 2003, Karlsruhe. * ThinkPHP sponsert "PHP and friends"-Projekt auf dem LinuxTag *

Fred Merritt

23 years ago

Fred Merritt

23 years ago
Sorry, I'll try again Why is dumping debug to the log more professional?? When I want debug information, I usually want it quick. It takes 2 seconds to add a var_dump or whatever, upload the change, and reload the page. Whatever gets the job done quickest seems more professional to me. Best regards. . . Fred Björn Schotte wrote:

Wez Furlong

23 years ago
Can you guys take this thread off the internals@ list please. ----- Original Message ----- From: "Fred Merritt" <fred@argus.pt> To: <internals@lists.php.net> Sent: Thursday, July 03, 2003 7:16 PM Subject: Re: [PHP-DEV] Re: var_dump_html()