CodingForums.com

CodingForums.com (http://www.codingforums.com/index.php)
-   Post a PHP snippet (http://www.codingforums.com/forumdisplay.php?f=41)
-   -   my take on a better print_r() and var_dump() (http://www.codingforums.com/showthread.php?t=230042)

Leeoniya 06-21-2011 10:38 PM

my take on a better print_r() and var_dump()
 
1 Attachment(s)
hello fellow PHPers,

finally i got around to making something which i feel is a much improved, lightweight and tweakable combo of print_r() and var_dump(). i bet 90% use-cases for these functions dump into a browser, not a text editor, so why not use everything HTML/js has to offer?

there are plenty of other alternatives (dBug, debuglib, wtUtil, krumo, kint, php dump, Debug::dump), but none that lived up to my minimalist, lightweight, configurable and non-verbose desires. dump_r is completely CSS-styled, plus there are additional classes added that can usefully categorize items such as "type" "subtype" "empty" "numeric"

currently, the functionality is more-than-adequate, but is always a work in progress. i have my TODO list in the Issues section. feel free to fork, make pull requests or report any bugs or enhancements.

for folding/unfolding, the example page links jQuery 1.6.1 and uses a small dump_r.js file to initialize the click handlers. it would be pretty easy to kill the jQuery dependency with some good ole' fashion plain DOM js, but i didn't feel like it since most of my projects already have it loaded :)

https://github.com/leeoniya/dump_r.php

would love some feedback. happy dumping!
leon

Inigoesdr 06-21-2011 10:50 PM

1 Attachment(s)
It's definitely minimalist. :)

If I were going to use something outside of the core functions for dumping I generally use dBug because I find the cfdump-style a lot easier to read for larger objects. But, I'm sure this will be useful to people.

Leeoniya 06-21-2011 11:34 PM

thx! but ouch, screenshot with cleartype/D2D rendering makes eyes hurt :(

i attached a clearer + fuller png to OP

Leeoniya 12-23-2011 12:49 AM

1 Attachment(s)
some refactoring and quite a few improvements made. including circular references, relative date indicators, callbacks, xml namespace stripping, removed jquery dependency for folding interaction, moved all code to a single file for easy inclusion.

attaching updated sample image, since i can't seem to edit the original post here.

Durex 01-27-2012 06:31 PM

The second one is much better.
Much more clean and that makes it more clear.
It will be very useful for a lot of people.

Leeoniya 01-27-2012 07:36 PM

you can modify the css stylesheet to your needs - it can be made to look as clean as you'd like.

EDIT: also, welcome to CF!

bonatoc 06-13-2012 09:45 PM

Hi Leon,

Great work. Of course a bit slow on extra large arrays, but the code is already so thin. Very convenient dev utility.

A question though :
Is there an option for having all children folded as an initial state, when debugging an array ?

Thanks

Leeoniya 06-13-2012 11:18 PM

you can already define how deeply you want to unfold initially. from the example, this will only unfold 1 level deep:

PHP Code:

dump_r($obj1); 

you should be aware, though, that the library currently does NOT stop recursion at that depth, it always dumps everything and builds the full HTML. this parameter only sets the necessary CSS to hide deep stuff from you on initial render. i was considering adding an option that would in fact stop the recursion, and not render the rest of the object, leaving you unable to unfold it later. as for the performance, i'm not sure if what you're seeing is just the browser's sluggish HTML rendering of such a huge DOM structure (this would cause slow interactive folds/unfolds also), or the library itself taking a long time to digest the object. i dont see anything that can be done about slow DOM performance unfortunately, except falling back to rendering a <pre> with the contents of either var_dump() or print_r() past a predefined depth - but that aint pretty - i'd rather just not render anything. the object analysis itself i have not benchmarked but i tried not to leave too many low hanging fruit there while still maintaining the useful stuff.

can you give me an idea of size and format of the structure you're dumping and into which browser? maybe a specific analysis function is taking a disproportionately long time. i've personally dumped some pretty large stuff without experiencing noticeable slowness.

Leeoniya 10-12-2012 07:10 AM

update! play with the output example at http://o-0.me/dump_r/

Leeoniya 11-28-2012 12:30 AM

dump_r() is now installable via Composer (http://getcomposer.org/)

just add "leeoniya/dump-r": "dev-master" to the "require" section of your composer.json file.

https://packagist.org/packages/leeoniya/dump-r

Leeoniya 01-19-2013 05:38 PM

1 Attachment(s)
The code was getting soupy, so it went through a full OOP/PSR-0 rewrite. Additionally, it will dump uniform arrays of objects or assoc arrays as record tables. See attached screenshot or try it out at http://o-0.me/dump_r/

Unfortunately as a result the lib is no longer a single file, though it's still a single-file-include, whether installed through Composer or without. Also, the way in which it can be extended has improved significantly over the prior version.


All times are GMT +1. The time now is 08:51 PM.

Powered by vBulletin®
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.