Log4php
  1. Log4php
  2. LOG4PHP-141

Allow setting of a default Renderer for all Classes

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.3.0
    • Component/s: Code
    • Labels:
      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.

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

        Issue Links

          Activity

          Hide
          Ivan Habunek added a comment -

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

          Thanks, Igor.

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

          Not planned for 2.2.

          Show
          Ivan Habunek added a comment - Not planned for 2.2.
          Hide
          Florian Semm added a comment -

          only a patch, because i want a review

          it also includes the fix from LOG4PHP-127

          Show
          Florian Semm added a comment - only a patch, because i want a review it also includes the fix from LOG4PHP-127
          Hide
          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'

          Show
          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'
          Hide
          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!

          Show
          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!
          Hide
          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.

          Show
          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.
          Hide
          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.

          Show
          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.
          Hide
          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

          Show
          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

            • Assignee:
              Ivan Habunek
              Reporter:
              igor nadj
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development