Brainstorming "debug" support


#1

I wanted to share some of the plans for the “Debugging”. Currently you may be missing that model->debug() option, if so - sit tight because a good support for debugging is coming soon. It will take me a few steps to explain.

  1. You need to know about PSR-3, which defines a Logger interface. With that you can find 3rd party loggers for your liking: https://packagist.org/search/?tags=psr-3

  2. Agile UI will also implement it’s own logger interface through “UserLogger” view. This view will store messages inside user session and let you examine them in detail through the native UI of Admin interface (pull-down menu)

  3. To make use of your logger, you would need to do something as trivial as $app->logger = $app->add('UserLogger');

  4. The new Console (https://github.com/atk4/ui/pull/280) also implements logger, so if you run code inside the callback, it will automatically intercept it to display in the console.

  5. You can make use of a “Proxy” logger, configure your own logic where to send different messages depending on the situation - e.g. production environment? send to Sentry.io. Development environment? Send to UserLogger.

  6. Audit implementation (https://github.com/atk4/audit) will also be able to act as a logger, so you can record actions into the database and link them up to users.

Now that I have explained how you would be able to retrieve debug info (and exceptions!), lets look at how you emit those.

  1. You need to “use \atk4\core\DebugTrait”. This adds a bunch of methods such as “log” and “debug”.

  2. Leave $this->debug('...') in your code. By default this won’t do anything.

  3. Use $any_object->enableDebug() for any object to enable it’s debug output.

  4. Leave $this->notice() in your code. By default it will be displayed to the user.

  5. Leave $this->warn() in your code when something looks bad. By default this will be logged but not shown.

  6. Leave $this->info() in your code. It will be treaded as breadcrumb (only displayed in case of error). See https://blog.sentry.io/2016/05/27/php-breadcrumbs.

With this, you can create your own components and models and regardless of the location be able to record some important information. PSR3 protocol supports passing of the “context”, like this:

$this->debug('Value of "limit" too high', ['limit'=>$limit]);

Finally, many of the existing objects in Agile UI and Agile Data will support debug.

  • atk4/data/Persistence will send queries as they are executed. It will include parameters as a context and will also provide you with an execution time for each query - helps you track slow queries.
  • atk4/data/Model will also output queries, as they are being built. So potentially they may not be executed at all, but you get to see them anyway.
  • atk4/ui/View will output their “render” form as well as “name” and probably will also inform you when children are added.
  • enabling debug inside the App will enable debug for all the other objects you add. (ouch).
  • maybe something else…

Sounds good enough? (this implementation would be scheduled for 1.5 release, ETA: February next year)


#2

Wow, that sounds great!
In the last few weeks, I often tried var_dump($some_object) to get debug information. But thats often not a good idea, as depending on the object it kind of triggers a chain that never seems to end, filling up the complete RAM of my machine and …
I think it was with Views that caused the external libraries to load.
Getting debug info this was seems a very good way, and the debug code can remain because it does not produce any direct output (as far as I get it).

Best regards
Philipp