8000 [WIP] var-dumper component by nicolas-grekas · Pull Request #4243 · symfony/symfony-docs · GitHub
[go: up one dir, main page]

Skip to content

[WIP] var-dumper component #4243

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Nov 5, 2014
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
section for DebugBundle/Twig integration
  • Loading branch information
nicolas-grekas committed Oct 29, 2014
commit ee2d7e473df3fea1929ca44bff1559cfb4b03276
12 changes: 12 additions & 0 deletions components/var_dumper/advanced.rst
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,18 @@ For example, to get a dump as a string in a variable, you can do::

// $output is now populated with the dump representation of $variable

An other option for doing the same could be::

$output = fopen('php://memory', 'r+b');
cloner = new VarCloner();
$dumper = new CliDumper($output);

$dumper->dump($cloner->cloneVar($variable));
fseek($output, 0);
$output = stream_get_contents($output);

// $output is now populated with the dump representation of $variable

Dumpers implement the :class:`Symfony\\Component\\VarDumper\\Dumper\\DataDumperInterface`
interface that specifies the
:method:`dump(Data $data) <Symfony\\Component\\VarDumper\\Dumper\\DataDumperInterface::dump>`
Expand Down
48 changes: 47 additions & 1 deletion components/var_dumper/introduction.rst
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,52 @@ The advantages of this function are:
so can you also use it directly.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would change this to: "dump() is just a thin wrapper for VarDumper::dump(). You can also call it directly."

You can change the behavior of this function by calling
:method:`VarDumper::setHandler($callable) <Symfony\\Component\\VarDumper\\VarDumper::setHandler>`:
calls to ``dump()`` will then be forwarded to ``$callable``, given as first argument.
calls to ``dump()`` will then be forwarded to ``$callable``.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not relevant in an introduction. That's something for further usage (advanced).


Where does the output go?
-------------------------

If you read the advanced documentation, you'll learn how to change the
format or redirect the output to wherever you want.

By default, these are selected based on your current PHP SAPI:

- on the command line (CLI SAPI), the output is written on `STDERR`. This
can be surprising to some because this bypasses PHP's output buffering
mechanism. On the other hand, this give the possibility to easily split
dumps from regular output by using pipe redirection.
- on other SAPIs, dumps are written as HTML on the regular output.

DebugBundle and Twig integration
--------------------------------

The `DebugBundle` allows greater integration of the component into the
Symfony full stack framework. It is enabled by default in the dev
environement of the standard edition since version 2.6.

Since generating (even debug) output in the controller or in the model
of your application may just break it by e.g. sending HTTP headers or
corrupting your view, the bundle configures the `dump()` function so that
variables are dumped in the web debug toolbar.

But if the toolbar can not be displayed because you e.g. called `die`/`exit`
or a fatal error occurred, then dumps are written on the regular output.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the components section. We should move all Symfony framework related things (bundles, web dev toolbar, etc.) to a cookbook article in cookbook/debug.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm mixed on this: scattering won't help the reader. This is not unprecedented: many other components tell about their configuration parameters.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please give an example? Those should be fixed too. The component docs are purely meant for standalone usage

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hum, not much in fact. In routing/hostname_pattern.rst?


In a Twig template, two constructs are available for dumping a variable.
Choosing between both is generally only a matter of personal taste:

- `{% dump foo.bar %}` is the way to go when the original template output
shall not be modified: variables are not dumped inline, but in the web
debug toolbar.
- on the contrary, `{{ dump(foo.bar) }}` dumps inline and thus may or not
be suited to your use case (e.g. you shouldn't use it in an HTML
attribute or a `script` tag).

Reading a dump
--------------

For simple variables, reading the output should be straightforward::

dump(array(true, 1.1, "string"));

.. _Packagist: https://packagist.org/packages/symfony/var-dumper
0