You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This idea just crossed my mind again while I was debugging a website. Would it be possible to move the debug view to a web developer panel in Firefox/Chrome/Safari?
Accessing the debug and profile information in the inspector would enable a few interesting features:
First and foremost, it would be possible to see the front-end page and the underlying XML at the same time (no more switching between different tabs that are not syncronised).
It would be also be possible to format and view event results in the web inspector directly (removing the need for a comment in the HTML. This should make event debugging much easier
As the default web inspectors already have a DOM tree view with collapsible nodes, this should be adaptable easily, see Collapsible XML Nodes #17.
A bit crazy, but as the debug mode knows all the templates and sources, it might even be possible to highlight the resulting HTML when hovering XML nodes in the "Symphony inspector".
It might even be possible to show Symphony logs in the console.
I know from experience that debug mode performance suffers severely when dealing with large XML sources, but I never experienced this kind of problem with the markup view in the web inspectors. So the debug mode could benefit from core web inspector optimisations.
Currently, if I use the debugger, I always trigger a separate request. Same is true for the profiler, which decouples my page view in the browser from the profiler results. For a Symphony Inspector the actual data of the page I'm viewing in the browser would be needed. Otherwise event results couldn't be displayed.
But is there a way for Debug Devkit to either deliver its results with the current browser request or at least for the current browser request?
From the top of my mind:
The extension would add a special http header to each request the browser makes. If Symphony sees it, it can then send all the content WITH the request: let's say in a hidden div. I've played with extensions in Chrome and could do this very easily.
Having to admin that I have no idea how this stuff works between server and browser, would it be possible to send two consecutive server responses ("one split in two parts") so that the browser starts rendering when the HTML part has finished but keeps receiving the rest?
I have actually no idea how devkits work but would be possible to transmit the results of all devkits at once
Yeah you could do it!
would it be possible to send two consecutive server responses ("one split in two parts") so that the browser starts rendering when the HTML part has finished but keeps receiving the rest?
HTTP2 can do this, but HTTP1 cannot. H2 is coming strong, but right now, it still hard to set up.
If you want to not delay rendering, you could put your html/xml/json in a script tag with the type="text/x-template" but you would still need to download the whole thing.
That being said, you could also issue a ajax request from the extension.
That being said, you could also issue a ajax request from the extension.
That sound better for performance. But how would I get the devkit results for exactly that page view in my browser? Making an AJAX request would trigger an additional request with different context (think event results).
Too complicated. The additional content will only get delivered to developers, right? (Of course one should be able to switch in it on and off nevertheless.)
I was just asking if there was another option because in case of large XML sources rendering for developers might be delayed notably – and it would be nice to prevent this. At least, I don't like to wait :)
@nilshoerrmann: Nor do I! I understand your concerns — but my biggest debug view is around 840 kB of XML (12.000 lines), but that would still be acceptable if you have a fast DSL connection. In this case Symphony's debug view is very very slow, so I must always use ?debug=raw.
So, all we need as a base for a Symphony Inspector is a bundled response of all devkits if a special request header is sent. Am I correct that this is more something Symphony should provide and not this specific debug devkit?
Okay, I haven't questioned the profiler and the debugger being separate extensions. This enables users to only add those devkits they really need, which is good.
My question is about where the response needed for a Symphony inspector panel would be emitted: Is it up to each devkit extension to add a comment with its results to the page on request or is this Symphony's responsibility?
I actually don't know how and where devkits hook into the system, but I though they were a core concept that's only used by extensions like this one or the profiler. Which makes a central point of emission logical in my eyes.
Let's say Symphony inspector panel add-ons for all browsers already existed. If opened, they would add a special header to the page requesting the devkit data.
Symphony would receive this header and fire a special delegate that would invite devkit extensions to return the markup needed for the inspector panel.
Those devkits supporting the inspector panels would respond to the delegate with the appropriate content and markup.
In the end, Symphony would take the responses of all devkits and combining them in a comment at the end of the returned page.
The add-ons would use the given markup in their inspector panels.
My question is about where the response needed for a Symphony inspector panel would be emitted: Is it up to each devkit extension to add a comment with its results to the page on request or is this Symphony's responsibility?
Yes it's extensions.
but I though they were a core concept that's only used by extensions like this one or the profiler.
Yeah they use the pub-sub pattern that is strangely only available to extensions. The whole core should work that way.
ok
Symphony would receive this header always and a special delegate that would invite devkit extensions to return the markup needed for the inspector panel. It would be up to the extension to findout the condition in which they need to act.
Activity
nilshoerrmann commentedon Jun 25, 2016
This idea just crossed my mind again while I was debugging a website. Would it be possible to move the debug view to a web developer panel in Firefox/Chrome/Safari?
brendo commentedon Jun 26, 2016
I'm don't know much about integrating with the developer panels, but it's a great idea!
nilshoerrmann commentedon Jun 27, 2016
I know that web inspector panels for JavaScript frameworks like Ember and React exist. They all seem to be based on common web technologies: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Anatomy_of_a_WebExtension
Accessing the debug and profile information in the inspector would enable a few interesting features:
I know from experience that debug mode performance suffers severely when dealing with large XML sources, but I never experienced this kind of problem with the markup view in the web inspectors. So the debug mode could benefit from core web inspector optimisations.
michael-e commentedon Jun 27, 2016
+1. I love this idea.
nilshoerrmann commentedon Jun 27, 2016
Question @brendo: How to create a developer panel seems to be well documented (e. g. https://developer.mozilla.org/en-US/docs/Tools/Adding_a_panel_to_the_toolbox). But is there a way for Debug Devkit to either deliver its results with the current browser request or at least for the current browser request?
Currently, if I use the debugger, I always trigger a separate request. Same is true for the profiler, which decouples my page view in the browser from the profiler results. For a Symphony Inspector the actual data of the page I'm viewing in the browser would be needed. Otherwise event results couldn't be displayed.
nitriques commentedon Jun 27, 2016
From the top of my mind:
The extension would add a special http header to each request the browser makes. If Symphony sees it, it can then send all the content WITH the request: let's say in a hidden div. I've played with extensions in Chrome and could do this very easily.
nilshoerrmann commentedon Jun 27, 2016
Nice idea! That would simplify the inspector a lot.
I have actually no idea how devkits work but would be possible to transmit the results of all devkits at once (xml, params, profile)?
nilshoerrmann commentedon Jun 27, 2016
Having to admin that I have no idea how this stuff works between server and browser, would it be possible to send two consecutive server responses ("one split in two parts") so that the browser starts rendering when the HTML part has finished but keeps receiving the rest?
nitriques commentedon Jun 27, 2016
Yeah you could do it!
HTTP2 can do this, but HTTP1 cannot. H2 is coming strong, but right now, it still hard to set up.
If you want to not delay rendering, you could put your html/xml/json in a script tag with the type="text/x-template" but you would still need to download the whole thing.
That being said, you could also issue a ajax request from the extension.
nilshoerrmann commentedon Jun 27, 2016
That sound better for performance. But how would I get the devkit results for exactly that page view in my browser? Making an AJAX request would trigger an additional request with different context (think event results).
michael-e commentedon Jun 27, 2016
Too complicated. The additional content will only get delivered to developers, right? (Of course one should be able to switch in it on and off nevertheless.)
nilshoerrmann commentedon Jun 27, 2016
Yeah, it would make sense to only request it, if the related inspector panel is opened.
nitriques commentedon Jun 27, 2016
That's why I would ship it with the current request. And that content is only sent when a specific browser extension is installed and running.
nilshoerrmann commentedon Jun 27, 2016
Yes, I understand that.
I was just asking if there was another option because in case of large XML sources rendering for developers might be delayed notably – and it would be nice to prevent this. At least, I don't like to wait :)
nitriques commentedon Jun 27, 2016
Until H2 is mainstream and well baked into php, we'll have delays sadly.
michael-e commentedon Jun 27, 2016
@nilshoerrmann: Nor do I! I understand your concerns — but my biggest debug view is around 840 kB of XML (12.000 lines), but that would still be acceptable if you have a fast DSL connection. In this case Symphony's debug view is very very slow, so I must always use
?debug=raw.nilshoerrmann commentedon Jun 27, 2016
@michael-e: Fair point.
So, all we need as a base for a Symphony Inspector is a bundled response of all devkits if a special request header is sent. Am I correct that this is more something Symphony should provide and not this specific debug devkit?
nitriques commentedon Jun 27, 2016
I like the current separation of debug vs profile. and the would response to a query string OR a HTTP header, which is simple enough!
nilshoerrmann commentedon Jun 27, 2016
In what way? Visually in terms of "having different URLs" / "having two tabs" or in terms of the technical implementation?
nitriques commentedon Jun 27, 2016
in terms of the technical implementation :)
nilshoerrmann commentedon Jun 28, 2016
Okay, I haven't questioned the profiler and the debugger being separate extensions. This enables users to only add those devkits they really need, which is good.
My question is about where the response needed for a Symphony inspector panel would be emitted: Is it up to each devkit extension to add a comment with its results to the page on request or is this Symphony's responsibility?
I actually don't know how and where devkits hook into the system, but I though they were a core concept that's only used by extensions like this one or the profiler. Which makes a central point of emission logical in my eyes.
nilshoerrmann commentedon Jun 28, 2016
Let me give an example:
Is this a feasible approach?
nitriques commentedon Jun 28, 2016
Yes it's extensions.
Yeah they use the pub-sub pattern that is strangely only available to extensions. The whole core should work that way.
receive this headeralways and aspecialdelegate that would invite devkit extensions to return the markup needed for the inspector panel. It would be up to the extension to findout the condition in which they need to act.