Debug Toolbar Enhancements

[lonnieezell]

Enhance the toolbar for better usability and display.

• Support and track AJAX requests
• Support additional data for timeline entries that will display just below the row when clicked, and be hidden at other times. Should have visual indicator. Primary use would be to display information about the queries - perhaps the first X characters in the query?
• Ability to be minimized to icon?
• Supports other display formats, mainly JSON and XML, that can be displayed based up on the format the client has requested.

Enhancement Checklist:

• Component(s) modified
• Unit testing updated
• User guide updated
• Securely signed commits
• Conforms to style guide

[pbellerive]

I can take a look at this. tell me more about ajax request attribute you want to display.
About data?

PS i know i will securely sign my next commit!

[lonnieezell]

That would be great! Basically, we want to be able to refresh the stats whenever an AJAX request is made. And it needs to be done in a way that just uses plain Javascript (no jQuery, etc). I'm not sure the best way to handle it at the moment. There's one for Laravel that handles this nicely. Others might exist out there, too, to get ideas on how they handle it. Basically, it handles it by saving the pre-rendered HTML and then creating a link to it I believe... which is then reloaded on refresh.

[pbellerive]

Ok, so in fact, you don't want to monitor request / response, but on a ajax request update current information in the debug bar , right?

[lonnieezell]

Correct.

[ghost]

http://phpdebugbar.com not fit?

[pbellerive]

I think we have a lot , simple . But phpdebugbar looks great.

[ghost]

Use phpdebugbar

[lonnieezell]

If you would like to convince us, then you might try actually providing arguments about why we should go with the package that your prefer, instead of just telling us to scrap it. While you're at it, let us know how you'd convince the community that including this particular third-party package is justified when we already have one that currently does 90% of the same stuff.

So, why do you like that one so much? What are the features you like about it? As far as I can tell from quickly scanning their site the only they offer that we don't already support is the AJAX handling.

[ghost]

@lonnieezell , Support AJAX is not enough. Sorry my english is not very good 😞

[lonnieezell]

That's fine. I'm still confused, though. AJAX isn't enough to make our bar better. So what is it missing? What do you wish it did that phpdebugbar already does?

[CodeBrauer]

I like to use https://github.com/JCSama/CodeIgniter-develbar - has most features and it's easy to use.

[natanfelles]

What about an icon/button (.ci-label) signalizing the AJAX requests?

We could do check a custom URI every x seconds and get the debug data. If an AJAX request is done by the app, we save the data info in a Session Flashdata and change the color of the icon, then if the user click it, the new HTML data is injected.

We could wrap the tabs (.tab) with a div with the main id and then enclose the new data in it. But I also thought about getting AJAX data in JSON (I have not yet analyzed this) and set up the HTML with JS.

[natanfelles]

The debug data can be saved by datetime in the browser local storage. To have a history. Then the debugbar view can be changed by some select input or anything like...

[lonnieezell]

@CodeBrauer I hadn't seen that one before. Looks pretty nice.

[lonnieezell]

@natanfelles I'm not sure the best way to handle the AJAX stuff. There's part of me that says it would be very handy to write the stats out to a separate file and simply call to include that file form javascript. That would allow comparisons between the requests, etc.

Obviously, that's part of a bigger deal and would require a bigger change, but it goes inline with something else we need to consider: providing the data in other formats, like JSON or XML based on the language the client has requested. I don't know that I've noted this one anywhere, but it's a biggie on my list in the grand scheme of things. I'll add that to the checklist above.

[SmolSoftBoi]

For AJAX or API requests, I was thinking debug information could be included in the response itself too, especially since you can't guarantee the requests originate from a browser.

[natanfelles]

@EpicKris The debug data included in a HTTP Header or manually called by the dev?

I think that to turn it more automatic a good approach would be sending a JSON (or XML?) string in a Header (CI-Debug).

CI-Debug: { "totalTime": "3.3", "totalMemory": "1.124", "timeline": [], "collectors": [] }

[natanfelles]

Having a Header with debug data, the HTML Bar already get the info to update in the AJAX response. Then is not more necessary stay tracking any URI.

[SmolSoftBoi]

@natanfelles I suppose having the debug data in the header would work, although I thought we could incorporate into the body of the response, much like the debug bar does now when viewing a typical page anyway, with a header that indicated debug data is available.

The debug bar could then check any AJAX responses if the header is available, then extract the debug data from its response and add it to the debug bar.

[lonnieezell]

Interesting thought to just cram all of the data into a header. It looks like 8k is our practical limit on the header size, so don't know if we'd run into issues with bigger sites or not.

Don't forget that a part of the grand plan is to be able to return the response in the same format as the response (JSON, XML, etc). Storing all of the data in a header does negate the need for that, but then we'd need to make it all templatable or soemthing to easily update based on the JSON response.

[natanfelles]

Is someone working on it?

With the new features of the toolbar we can detect the AJAX Requests and get the last cached debugbar file.

I did not any try yet, but, is the Toolbar script loader being added in AJAX Responses?

We can see it, and do not append the script tag but just to save the cache file. And in the HTML Toolbar show a new Label "AJAX" or

@lonnieezell what about an History label/icon with a Tab showing the history list, datetime, if is ajax or not, and a button in the item history to restore the toolbar at this point (but the History remains)?

---

It looks like the HTTP Header will not be used by default, but this would be great in API requests. So it might be good to save the data from the toolbar being serialized and when needed, unserialized. Then we can assemble both, the HTML output and the HTTP Header output and respond each one according to the requisition.

---

Or in place of the HTTP Header in JSON/XML request, to respond a toolbar key with the data. Like:

"toolbar": { "totalTime": "3.3", "totalMemory": "1.124", "timeline": [], "collectors": [] }

It can solves the limit issue with HTTP Servers.

---

Well, if someone want to talk about and point some directions, please do it. Tomorrow I'll start writing something along that line and then open a PR if no one is dealing with this subject at the moment.

[jim-parry]

Closing. Further enhancements can be raised on the forum or as separate issues/PRs.