ezrpg-legacy / ezrpg-2.0.X-discontinued-

http://ezrpgproject.net
Other
6 stars 0 forks source link

Perhaps a debug console similar to Smarty's {debug} #5

Open uaktags opened 11 years ago

uaktags commented 11 years ago

Personally I'm in favor of a debug console, something where if we set debug to true and are an admin / have privledges to see debug console, a popup appears that displays var_dump($this). We could maybe even extend it further with more messages that'd wed want to see organized and displayed when need be. I normally have been including

<?php var_dump($this) ?>

or

<?php var_dump($this->get('variable')) ?>

in my views to debug whats going on when something doesn't work (or test it when it does work :-P) 13 - 1

Perhaps a check in the ezRPG\View file during render would suffice, to check for a config setting of debug set to T/F, then just load/reload the popup window. We don't have any templating style syntax, so we can't do like a {debug} to initiate, but perhaps a $this->view->debug(true) in the controller to initiate that we want it displayed (if we want to be selective about our console) could also work.

ferdis commented 11 years ago

I fear that you're going about this incorrectly...

A debug console would ideally show events that transpired while the application started up/executed. You'll need to unify information generated by all objects: this includes other objects than only the view.

To have this, you can implements PSR-3 logging utility which would additionally(through the debug() method) contain stacks of the objects(variables, containers, etc).

It would be much easier to add an access control onto that than a primitive function call based on a conditional. The debugging console itself can be a simple view, which is appended after the template has loaded.

uaktags commented 11 years ago

I think my thought of a debug console differs quite a bit from yours, as per the second statement you made. My usage with smarty's debug console was a dump of all variables being accessible in the current view whereas yours sounded alot like a print out of a stack trace, showing a detailed path of where and when everything happened before something went wrong. While, imo, that's great for when something goes wrong, i find that to be a bit of overkill when wanting to see just what things are assigned. My debugging mainly revolves around just trying to find logical errors, see what variables/objects are actually being valued as compared to what I'm expecting them to be valued at. I'm not looking to catch anything at any point, but mainly just display what values what after the page is loaded.

Perhaps a best of both worlds would do as well, a tabbed console that shows what the View object holds, and a tab that shows a trace of events that passed since the Controller/View were initiated.

The PSR-3 Log seems more like an implentation that we should strive to look at with our Error Handling system also, to give a bit more options instead of just throw new \exception

ferdis commented 11 years ago

Well, to just get all of the user-defined variables:

var_dump($this->variables);