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
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/
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!
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
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!
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
PresidentMarco Tabini & Associates, Inc.
28 Bombay Avenue
Toronto, ON M3H 1B7
CanadaPhone: (416) 630-6202
Fax: (416) 630-5057
Web: http://www.tabini.ca
What could it possibly colorize and how would it be useful?
epplestun wrote:
In my opinion is good idea but Derick has rason, is better if var_dump_html
colorise the output :-)
Quoting Derick Rethans derick@php.net:
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/--
--
Ken Tossell
ken at tossell dot net
http://www.kennyt.com/
washington, dc / gmt-4
world::free.capital();
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 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:
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
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
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
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 removevar_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
- 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 *
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
- 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 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
- 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 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