-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
[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
Changes from 1 commit
26edf7a
5e0b9bd
7dc6e5c
036edcb
350e0c7
2fc3811
b5b45bc
ee2d7e4
cb0ee89
6a3e170
edb0ff9
c578fe7
23712fb
041e858
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -45,6 +45,52 @@ The advantages of this function are: | |
so can you also use 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``. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
There was a problem hiding this comment.
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 forVarDumper::dump()
. You can also call it directly."