option to show expanded by default? about krumo HOT 9 CLOSED

In 0.4.4 you can do the following:

krumo::$expand_all = 1;
krumo($a);

We may, in the, future add an option where you can do:

krumo($a, KRUMO_EXPAND_ALL);

But that's not available yet.

from krumo.

Ok you talked me in to it... I added KRUMO_EXPAND_ALL. Here is the checkin

scottchiefbaker@06766f4

It will be available in the next official release. You're welcome to try it now, and test it for us.

from krumo.

Thanks, it's working perfectly as far as I can tell.

from krumo.

So what's the point of copying functionality from Kint and reimplementing it in worse^[1] approaches while gaining nothing?

Will you copy my parsers too? Cause I've spent countless hours to extract every bit of information from every possible type of dumped variable. I've worked around $GLOBALS (which is always passed by reference even if you copy it), I handled recursion properly - I detect it one level higher than it's simple to do, I handle all kinds of weirdly hardcoded objects into the bowels of PHP, I've encountered dozens and dozens of bugs that I've sunk time in to fix. You do know, that reflection only returns part of the object properties? But so does casting it to array...

And that's all just for the basic variable parser.

You can't not copy this, that is the very firstmost requirement for a dumper, isn't it?

Why play catch up when we could act in the spirit of open source and team up. Don't you like something about Kint? I'm here and very active, how can I improve it so you'd feel better about it? I'm making it with a forever free promise and a MIT licence, and my first priority for 1.0 release is make it as contributors friendly as possible.

There really is no point of making contests here, at the end of the day, we are creating development tools and PHP is fragmented as it is, let's make something de-facto and best in all senses of the word!

If you are not willing to jump ship, I can understand that, but I'd like a discussion on why and whether there's something I can do about that...

^[1] much more characters to type for the user, global space littered with constants, only one possible parameter to dump.

from krumo.

I don't think any of us have anything against Kint. I used Kint for the first time last week, and I think it offers a lot of great features. The reason I continue to develop Krumo is because I've been using it for years, and it does everything I need it to. I have very simple needs, basically printing complex arrays, and Krumo does this very well.

I don't see the existence of Kint and Krumo being a bad thing. Like any good open source project there are often many different implementations of the same concept. I'd be happy to contribute to Kint too, I just need to get more familiar with it first.

from krumo.

I feel partially responsible for this discussion because of asking for the feature.

I just wanted readable var_dumps without having to have xdebug installed. I was trying out both packages to see which one provides that simple feature and nothing else. To me this requires two things.

1. default expanded
   I don't want to have to grab the mouse and go through expanding everything to see something I know is going to be a few levels down. Maybe this could be a config option rather than a function.
2. clean and light weight theme
   schablon.com skin in Krumos was the closest. Even that one has what I consider unnecessary border around it but no big deal.

My thinking was that any var_dump() package should have 'expanded by default' and asking for that was better than asking for an entire new light weight theme to be added to Kint. Actually I'd like to make the 'light' theme and submit a pr for either or both packages.

In the end I went with the chrome extension var_dumpling(). It really is all I need for simple var_dump debugging. But I can see a more robust package like Kint or Krumos could be benefitial for more complex situations.

I appreciate all the hard work you both put into these projects. Especially considering they are free to use. I also know you both are researching and discussing improvements for your next releases.

That being said I'll list what I don't like about both packages at their current release. I think these changes would greatly improve them and increase their usage.

1. Needs to be psr-0 compliant namespaces and a structure similar to the following

src
|---packagename
     |---packagename(where other package specific directories and classes resided)
     |---config
          |---config.php
     |---other files (license, composer.json, etc)

In composer.json

"autoload": {
       "psr-0": {
            "namespace": "src/"
        }

1. main class checks for existance of app/config/packages/packagename/config.php and uses it or otherwise uses the one at packagename/config/config.php

If the config file is in the location above Laravel users can run

php artisan config:publish --path="vendor/repo/packagname/config" repo/packagname

and it will by default be published to app/config/packages/packagname/

Instructions for non framework users could be to manually copy the config file to this same location in their app if they wish to override config options.

1. super light weight theme as mentioned above
2. default setting in the config for things like expanded vs collapsed
3. prefix the function names with k for Kint or k for Krumos so they don't interfere with
   dd() which I know exists in Laravel and may exists in other frameworks. Of course Laravel could have called theirs ld() . Both having kd() shouldn't be a problem because trying them both out should be the only reason they would both be installed at the same time. On that note developers could make their own helper file to call it and then use dd() or what ever they want.
4. cli detection and kd() with no html and no pre tags. I see Kint is already working on this.

Although I mention Laravel several times these changes are all really framework agnostic I think. I also know this is a lot of refactoring and restructuring. No complaints here, just stating my opinion on what both packages need. And I'm willing to contribute what I can.

from krumo.

I'll briefly reply but I'm away from the computer and will post a full answer when I get back.

• Kint::$expandedByDefault = true; is the setting you're looking for. Or you can use s() and sd() for a text-only output with much of the Kint goodies intact. There's a white theme too: http://transfercroatia.com/transport/web/kint/examples/overview.php?theme=aante-light
• Kint cli detection and coloring is already done, it could do with some refractoring and user feedback, but it's stable and useable.
• I can't use PSR-0 because I'm aiming to support all php 5.x versions, not just 5.3 and above. But I am going to refractor Kint before releasing 1.0 - with focus on ease of extending and contribution. Thanks for the config suggestions though, I'm researching this heavily and asking laravel users for any insight and suggestions.
• While there's an easy workaround for enabling Kint's dd instead of the one from laravel, when I properly sort out the config issue, shorthand functions will become easily customized to the users whim.
• I am fully aware of the huge lack of documentation for the vast featureset of Kint. I will remedy this ASAP.

Some of the mentioned functionality is only present in the Kint 1.0 branch here in github, check it out if you like.

from krumo.

Is this solved for you @isimmons can we close the issue?

from krumo.

This issue can be closed.

from krumo.