Default-Layout

[Florian Semm <fl...@gmx.de>]

Am 25.11.2011 22:20, schrieb Ivan Habunek:
>
> The idea I had was to implement it in the activateOptions() method of
> the base class LoggerAppender. If no layout is present then set a
> default layout. You just have to make sure the
> parent::activateOptions() is called in Appenders which override this
> method. Or if you have a better idea, please say.
>
> [1] https://issues.apache.org/jira/browse/LOG4PHP-160

I have implemented this case. But there's a problem: if this will 
implemented in the activateOptions() method, you have to modify all 
appenders which overwrite this method. The createAppenderLayout() method 
in the LoggerConfigurator is a better place. You can call there a method 
like getDefaultLayout() or a static variable.


> Regards,
> Ivan

Regards,


Florian

Re: Default-Layout

[Florian Semm <fl...@gmx.de>]

Am 27.11.2011 12:08, schrieb Ivan Habunek:
> On 26 November 2011 19:09, Florian Semm<fl...@gmx.de>  wrote:
>> I have implemented this case. But there's a problem: if this will
>> implemented in the activateOptions() method, you have to modify all
>> appenders which overwrite this method. The createAppenderLayout() method in
>> the LoggerConfigurator is a better place. You can call there a method like
>> getDefaultLayout() or a static variable.
> I can see the problem. I wanted to keep the solution within the
> appender class because, if it's defined in the configurator, then the
> default layout will not be applied when configuring programatically.

in the future i have to notice the two ways of configuration: 
config-file and programatically

> For example, this would not work becuase the layout is not specified:
> $app = new LoggerAppenderEcho();
> $app->activateOptions();
> $app->append("foo");
>
> Maybe we can implement it so default layout is set automatically in
> Appender's constructor. The configurator will override the default
> layout if it's specified in the config file. This way it works
> programatically, but it would be just slightly slower, because the
> layout would potentially be set twice.

the constructor is a good way. if we do this then we haven't to modified 
other appenders. to check if the layout is needed is a little 
performance tweak ;)

> On the other hand, I don't suppose a lot of people will configure
> log4php programatically...

if you use log4php in a symfony-project and you have special-appenders 
like a doctrine2-appender, you have to extend the LoggerAppender. in 
this case you have some constructor-injections [1]. on the other hand 
you don't need any layout for a db log ;)
maybe a doctrine-appender is a bad example, but it is possible to 
configure it programatically. ;)

[1] https://github.com/floriansemm/Log4PhpBundle/wiki/Symfony-Service

> On the third hand, we haven't done any performance tuning at all so
> the framework is not very optimised to start with, and this minor
> performance penalty will not be detectable. :)
>
> What do you think is the better solution?
>
> Regards,
> Ivan

regards,

Florian

Re: Default-Layout

[Ivan Habunek <iv...@gmail.com>]

On 26 November 2011 19:09, Florian Semm <fl...@gmx.de> wrote:
> I have implemented this case. But there's a problem: if this will
> implemented in the activateOptions() method, you have to modify all
> appenders which overwrite this method. The createAppenderLayout() method in
> the LoggerConfigurator is a better place. You can call there a method like
> getDefaultLayout() or a static variable.

I can see the problem. I wanted to keep the solution within the
appender class because, if it's defined in the configurator, then the
default layout will not be applied when configuring programatically.

For example, this would not work becuase the layout is not specified:
$app = new LoggerAppenderEcho();
$app->activateOptions();
$app->append("foo");

Maybe we can implement it so default layout is set automatically in
Appender's constructor. The configurator will override the default
layout if it's specified in the config file. This way it works
programatically, but it would be just slightly slower, because the
layout would potentially be set twice.

On the other hand, I don't suppose a lot of people will configure
log4php programatically...

On the third hand, we haven't done any performance tuning at all so
the framework is not very optimised to start with, and this minor
performance penalty will not be detectable. :)

What do you think is the better solution?

Regards,
Ivan