[TYPO3-dev] Status of "devlog" extension

[Steffen Müller]

Hi.

On 02.06.2013 15:26 Xavier Perseguers wrote:
> 
>> Hence the question (my memory of looking at the Logging code is fuzzy):
>> is it possible to set up several Log configurations, so that
>> "syslogging" could be done on one side and "devlogging" on another side,
>> i.e. log entries in these two "contexts" don't get written to the same
>> outputs (be it files, DB tables or whatever else). I can't imagine
>> having these two targets mixed up together.
> 

yes, handling loggers in a different way is possible, for example by
configuring a dedicated logWriter a certain loggers, identified by name
(see example below).

I wonder how you define devlogging and syslogging? what makes the
difference?
We really need all your input here to create a coherent concept of
Logging in TYPO3. No technical concept, but one describing goals and
approaches to tackle different use cases/scenarios.


> I second that and would like to even get 1 tiny step further:
> 
> - Define context based on "syslogging" + "devlogging" for different
> outputs (e.g., file-sys.log and file-dev.log)
> - Filter by extension/module, whatever is supported as parameter while
> logging something. Example would be to write devlog info to some file
> but only related to extension X, not everything else.
> 
> My little dream (it is allowed to dream, isn't it?) would be something
> like that:
> 
> $whateverCentralLog->startContext('my-context');
> 
> // life of extension call
> 
> $whateverCentralLog->endContext('my-context');
> 

What does "life of extension call" mean? Can you give us some scenarios?

The most important question to me is: can we avoid adding debugging
logic to our classes except the log calls?

I'd like to avoid:
function add($arg1, $arg2) {
  if ($myContext) {
    debug('foo');
  } else {
  return $arg1 + $arg2;
}

but rather see:
function add($arg1, $arg2) {
  debug('foo');
  return $arg1 + $arg2;
}

and then control from an outside configuration, if foo should be logged
or not. This would allow administrators to handle logging without
touching the code.

Here's an example how to set a logWriter for a certain class:

Each logger of a class has a custom name, so you can control the
behaviour of a logger.

Usually we use  __CLASS__ as the name:

<---- snip
namespace Snakeoil\ExtBite\Domain\Model;

class Foo {

  public function __construct {
    $logger =
\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\CMS\Core\Log\LogManager')->getLogger(__CLASS__);
  }

  function bar() {
    // do whatever bar should do.

    $logger->info('Everything went fine.');
  }
}
<---- snap

You canconfigure the behaviour of the log calls of this  particular
class inside of
$GLOBALS['TYPO3_CONF_VARS']['LOG']['Snakeoil']['ExtBite']['Domain']['Model']['Foo']


If you want to log "Everything went fine." to the file
"typo3temp/logs/Foo.log" then you'd need this setting:

$GLOBALS['TYPO3_CONF_VARS']['LOG']['Snakeoil']['ExtBite']['Domain']['Model']['Foo']['writerConfiguration']
=> array(
  \TYPO3\CMS\Core\Log\LogLevel::DEBUG => array(
    'TYPO3\\CMS\\Core\\Log\\Writer\\FileWriter' => array(
      'logFile' => 'typo3temp/logs/Foo.log'
    )
  )
);

you could also log every event triggered in your extension by:
$GLOBALS['TYPO3_CONF_VARS']['LOG']['Snakeoil']['ExtBite']['writerConfiguration']
=> array(
  \TYPO3\CMS\Core\Log\LogLevel::DEBUG => array(
    'TYPO3\\CMS\\Core\\Log\\Writer\\FileWriter' => array(
      'logFile' => 'typo3temp/logs/ExtBite.log'
    )
  )
);

You could also write these logs to the devlog table of the devlog
extension and stick to the devlog backend module. All you'd need is a
custom LogWriter to map the LogRecord properties to the devlog DB fields.

You are not forced to use __CLASS__ as the logger name (although it is
recommended). __CLASS__ gives you a namespace hierarchy, which makes it
very flexible to configure.
You could use any string as name, for example 'deprecated'.

$logger =
\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\CMS\Core\Log\LogManager')->getLogger('deprecated');

$logger->warning('function foo() is deprecated. Use bar() instead');

Since all classes should be treated equal in case of deprecation
logging, this makes sense here


Anyone of you at the TYPO3camp Stuttgart next weekend? I'm planning to
give an introduction to the Logging API.

-- 
cheers,
Steffen

TYPO3 Blog: http://www.t3node.com/
Twitter: @t3node - http://twitter.com/t3node