Arrivederchi Ciao Chau Symfony … Welcome Standalone Dumper & C Extension

You start with requiring the dependency on the component like this:

"patchwork/dumper": "~1.2@dev",

The component also does not get tagged very often so you will need master to get the function twig below explained. You can install it also together with ladybug to compare :).

After adding the above:

"raulfraile/ladybug": "~1.0.8",
"patchwork/dumper": "~1.2@dev",

You can require the bundle from ladybug too if you want for the twig function. You can also plug the dumper twig function plugging the bundle that already comes within the patchwork/dumper:

if ('dev' === $this->getEnvironment()) {
            // ...
            $bundles[] = new Symfony\Bundle\DebugBundle\DebugBundle();
            $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
            // ...
        }

Of course as usual I do not recommend to load bundles. So what I do instead is to plug the twig extension straight to the kernel if possible. Now it is time to focus on the component. After this DebugBundle is plugged you can invoke it from your view too:

The function dumps to the same view the variable var:

{{ dump(var) }}

Where as the dump tag only presents a screenshot in miniature on the symfony WDT (Web Development Toolbar) and waits for you to click there so that it will take you to the sidebar-ed view in white that is also expandable:

{% dump var %}

I fully prefer the dumping directly on the view since it is less time wasted. Also it works the same as in the cli so there is nothing new to learn. I tested side to side to ladybug and I think ladybug still has some information that can get expanded and it is what I am more accustomed to. However ladybug often breaks whereas this component is very solid and integrates nicely with symfony and has a dark background which I like very much.

Some examples borrowed from the PR in symfony follow. Notice the beautiful dumping of the container:

Source: patchwork dumper component on github.

Now a comparison side to side of dump vs var_dump:

Screenshot 2014-09-17 21.20.32 Source: patchwork dumper component on github and my desktop screenshot.

Ladybug colors fall short a bit, but still is a good option. However the reach of the dumper component is way beyond since it comes with a C extension that can be compiled:

 phpize
./configure
make
sudo make install

However honestly until this is easy to install as:

brew install php56-symfony_debug

I will not be able to use it nor I want to use it since I rather fallback to the php implementation.

The view of ladybug is expandable in a nice way:

Source: Github LadybugBundle.

Notice ladybug has also a bundle but I rather don’t use the bundle though sometimes it comes handy for a dump on the view. The thing is I think many other packages would like to use this component totally independent from symfony, however creating a dependency on this will pull several other dependencies right away:

"require": {
        "php": ">=5.3.3",
        "symfony/config": "~2.4",
        "symfony/dependency-injection": "~2.2",
        "symfony/event-dispatcher": "~2.3",
        "symfony/http-kernel": "~2.3"
    },
    "require-dev": {
        "twig/twig": "~1.12"
    },

Really a bunch more since the DI thing and others will be a load of things.

What I think I will use in my projects will be the component but will try to untie as much stuff as possible and wire things with say the aura DI or try at least. The component in itself should just be invokable via:

use Symfony\Component\VarDumper\VarDumper as Dumper;
 
Dumper::dump($var);

And here is the implementation detail:

    public static function dump($var)
    {
        if (null === self::$handler) {
            $cloner = extension_loaded('symfony_debug') ? new ExtCloner() : new PhpCloner();
            $dumper = 'cli' === PHP_SAPI ? new CliDumper() : new HtmlDumper();
            self::$handler = function ($var) use ($cloner, $dumper) {
                $dumper->dump($cloner->cloneVar($var));
            };
        }
 
        return call_user_func(self::$handler, $var);
    }
 
    public static function setHandler($callable)
    {
        if (null !== $callable && !is_callable($callable, true)) {
            throw new \InvalidArgumentException('Invalid PHP callback.');
        }
 
        $prevHandler = self::$handler;
        self::$handler = $callable;
 
        return $prevHandler;
    }

Let the reader understand a bit. Basically it uses a cloner within the handler that gets called finally to dump the variable $var. It switches between the html or cli dumpers accordingly. And depending on if the C extension is preloaded it will choose the respective XCloner::class. The high level handler callable will use the respective implementations to do the final job invoking each.

That is it! So before 2.6, even now you can take advantage of this nice component and plug it into your say AuraPHP project or other. It will rock and you will not have to wait for 2.6 release nor for the big merge of the PR that smashes it into the whole of bulk of symfony/symfony.

If someone plugs the C extension on brew please let me know!

Leave a Reply

Your email address will not be published. Required fields are marked *