8000 [Var-dumper] Use HtmlDumper without the provided styles · Issue #16618 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content
8000

[Var-dumper] Use HtmlDumper without the provided styles #16618

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

Closed
staabm opened this issue Nov 21, 2015 · 7 comments
Closed

[Var-dumper] Use HtmlDumper without the provided styles #16618

staabm opened this issue Nov 21, 2015 · 7 comments

Comments

@staabm
Copy link
Contributor
staabm commented Nov 21, 2015

ATM it is not easy to use the var-dumper and its HtmlDumper without all those styles which come with it.
As the default colors doesnt look good in our app I tried setStyles, which doesnt override builtin styles nicely, because it only overrides certain aspects.
That means I can override everything built in now, but new versions which might define new styles wont work (so no forward compatibility).

at best I could just do $dumper->setStyles(array()); but this does not change anything.

best I can do is

                $styles = array(
                    'default' => '',
                    'num' => '',
                    'const' => '',
                    'str' => '',
                    'note' => '',
                    'ref' => '',
                    'public' => '',
                    'protected' => '',
                    'private' => '',
                    'meta' => '',
                    'key' => '',
                    'index' => '',
                );
                $dumper->setStyles($styles);

but the component still generates some styles with padding,margin with the sf-dump classes.
Also this kind of override generates a lot of empty css selectors for nothing...

My use case is: re-use the existing expand/collapse functionality but without all the css brought with it.

@nicolas-grekas
Copy link
Member

I think you could overwrite getDumpHeader to amend the default css/js or use setDumpHeader to completely overwrite the css/js by your own, would it work for your use case? See also setDumpBoundaries just in case

@staabm
Copy link
Contributor Author
staabm commented Nov 29, 2015

@nicolas-grekas thx for your feedback. the actual question is, if this kind of changes should be possible thru the class api or if it is not and therefore is meant to be achieved by subclassing..

@nicolas-grekas
Copy link
Member

I think it can be done both ways:

  • call the default getDumpHeader, alter its result then setDumpHeader
  • or specialize getDumpHeader

I've no preference for now. Do you have one?

@staabm
Copy link
Contributor Author
staabm commented Nov 29, 2015

call the default getDumpHeader, alter its result then setDumpHeader

sounds like something which heavily relies on impl. details... therefore I dont like it.

or specialize getDumpHeader

This means I need to subclass and override, right?

Maybe just adding a flag to setStyles which indicates whether it should override all styles instead of a certain key only? (which it does right now, because of merging the given styles into the current ones)

setStyles atm works like a method I would have named putStyles or addStyles...
setXX methods should override everything instead of changing things incrementally IMO. But this is something we cannot change without BC breaks..

@javiereguiluz
Copy link
Member

@nicolas-grekas could you think about this feature request? If implemented, we could use VarDumper whenever we need to dump variables in Symfony (which is a very common need, as explained in #18074). Thanks!

@nicolas-grekas
Copy link
Member

@staabm one year later, what's you stand on this one? Can we close this issue? Or would you like to work on a PR?

@nicolas-grekas nicolas-grekas removed their assignment Apr 16, 2017
@staabm staabm closed this as completed Apr 16, 2017
@staabm
Copy link
Contributor Author
staabm commented Apr 16, 2017

The recent releases work pretty well for us, so no need for further changes from my side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
0