Uploaded image for project: 'Log4php'
  1. Log4php
  2. LOG4PHP-141

Allow setting of a default Renderer for all Classes

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.0.0
    • 2.3.0
    • Code
    • None

    Description

      In log4j you can set a default renderer for all Classes by configuring a Renderer for the Object class, as all Classes extend Object. But PHP does not have a base class like Java, and it would be nice to have a way to replicate this behaviour.

      Attachments

        1. LOG4PHP-141.patch
          10 kB
          Florian Semm
        2. log4php-21-02-2012.patch
          12 kB
          Florian Semm

        Issue Links

          Activity

            juice Ivan Habunek added a comment -

            Sounds like a good idea. We will look into this for v2.2.

            Thanks, Igor.

            juice Ivan Habunek added a comment - Sounds like a good idea. We will look into this for v2.2. Thanks, Igor.
            juice Ivan Habunek added a comment -

            Not planned for 2.2.

            juice Ivan Habunek added a comment - Not planned for 2.2.
            floriansemm Florian Semm added a comment -

            only a patch, because i want a review

            it also includes the fix from LOG4PHP-127

            floriansemm Florian Semm added a comment - only a patch, because i want a review it also includes the fix from LOG4PHP-127
            floriansemm Florian Semm added a comment -

            i have modified my last solution: you can setup your own costum-object renderer. it will overwrite the default-object renderer (see last patch).

            the setup looks like this:

            'renderers' => array(
            array('renderedClass' => 'Object', 'renderingClass' => 'CostumDefaultRenderer')
            )

            it isn't semantic correct, so i don't like this solution so much. maybe it's better to create an new attribute like 'defaultObjectRenderer'

            floriansemm Florian Semm added a comment - i have modified my last solution: you can setup your own costum-object renderer. it will overwrite the default-object renderer (see last patch). the setup looks like this: 'renderers' => array( array('renderedClass' => 'Object', 'renderingClass' => 'CostumDefaultRenderer') ) it isn't semantic correct, so i don't like this solution so much. maybe it's better to create an new attribute like 'defaultObjectRenderer'
            juice Ivan Habunek added a comment -

            I haven't had a proper look at the code yet because of the work on the release , but I have a few thoughts.

            I agree that it would be better to add a new attribute, rather than specifying "Object" for rendered class. Maybe just "defaultRenderer"? Do we plan to have any other renderers apart from object rendererds?

            Looking at the naming, I would prefer that the renderer interface be called LoggerRenderer instead of LoggerRendererInterface. To keep the same naming scheme as LoggerConfigurator interface.

            This is just some initial ideas. I will have a better look at the code for the weekend.

            Cheers!

            juice Ivan Habunek added a comment - I haven't had a proper look at the code yet because of the work on the release , but I have a few thoughts. I agree that it would be better to add a new attribute, rather than specifying "Object" for rendered class. Maybe just "defaultRenderer"? Do we plan to have any other renderers apart from object rendererds? Looking at the naming, I would prefer that the renderer interface be called LoggerRenderer instead of LoggerRendererInterface. To keep the same naming scheme as LoggerConfigurator interface. This is just some initial ideas. I will have a better look at the code for the weekend. Cheers!
            floriansemm Florian Semm added a comment -

            at the moment there are two default-renderer: one for objects, another for string/number/whatever. if we keep this default-renderer we need two new attributes.

            to change the naming is no problem.

            floriansemm Florian Semm added a comment - at the moment there are two default-renderer: one for objects, another for string/number/whatever. if we keep this default-renderer we need two new attributes. to change the naming is no problem.
            floriansemm Florian Semm added a comment -

            i have add an extra option to the renderer:

            'renderers' => array(
            array('defaultObjectRenderer' => 'CustomObjectRenderer')
            ),

            if there are other options like 'renderedClass' or 'renderingClass', there will be rejected.

            floriansemm Florian Semm added a comment - i have add an extra option to the renderer: 'renderers' => array( array('defaultObjectRenderer' => 'CustomObjectRenderer') ), if there are other options like 'renderedClass' or 'renderingClass', there will be rejected.
            juice Ivan Habunek added a comment -

            I have finished the implementation. Florian, I have made some changes to make the whole thing simpler.

            All renderers should implement LoggerRenderer interface. LoggerRendererObject has been removed since it's identical. LoggerRendererDefault is the initial default renderer which can be replaced by a custom one.

            See new docs here:
            http://bezdomni.net/log4php/docs/renderers.html

            juice Ivan Habunek added a comment - I have finished the implementation. Florian, I have made some changes to make the whole thing simpler. All renderers should implement LoggerRenderer interface. LoggerRendererObject has been removed since it's identical. LoggerRendererDefault is the initial default renderer which can be replaced by a custom one. See new docs here: http://bezdomni.net/log4php/docs/renderers.html

            People

              juice Ivan Habunek
              igornadj igor nadj
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: