PicoContainer
  1. PicoContainer
  2. PICO-215

Refactore to allow stateful PicoVisitor

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1-1-beta-2
    • Fix Version/s: 1.1
    • Component/s: PicoContainer (Java)
    • Labels:
      None
    • Number of attachments :
      0

      Description

      SITUATION:
      ========

      The current PicoVisitor realization is based on stateless implementations only. This is caused by the fact, that the traversal is started from a node's accept method and the visitor cannot really know, what is the first and what is the last visit of the traversal. Therefore no visitor implementation can be used to implement logic based on the collected results of a traversal.

      PROPOSAL:
      ========

      Addition of a method PicoVisitor.traverse(Object). This method will initiate the traversal and call the objects accept method. Call

      visitor.traverse(pico);

      instead of

      pico.accept(visitor);

      BENEFITS:
      ========

      • The LifecycleVisitor depends on a exact reversal of the visited components. Therefore the PV.isReverseTraversal method was introduced. Unfortunately this makes the node's implementation responsible for the evaluation of the visitors traversal mode and forces all nodes with a composition pattern to implement a reverse traversal (see also number of calls to isReverseTraversal in http://www.picocontainer.org/versions/1.1-beta-2/clover/org/picocontainer/defaults/LifecycleVisitor.html). The proposed API would allow the implementation of a ReversalVisitor, that records all visits and execute them in reverse order on a delegated visitor later on. This would result in a clean implementation of all accept methods and allow the removal of isReverseTraversal at all.
      • The VerifyingVisitor could be enhanced. Currently it can only collect the exceptions verifying the CAs of one PC only (very similar to the old PC.verify behaviour), but with PV.traverse it could collect all exceptions of the complete hierarchy. Additionally the implementation can use a Map for the already verified components to prevent multiple verifications (PICO-166).

        Issue Links

          Activity

          Hide
          Jörg Schaible added a comment -

          Corrected description.

          Show
          Jörg Schaible added a comment - Corrected description.
          Jörg Schaible made changes -
          Field Original Value New Value
          Description SITUATION:
          ========
          The current PicoVisitor realization is based on stateless implementations only. This is caused by the fact, that the traversal is started from a node's accept method and the visitor cannot really know, what is the first and what is the last visit of the traversal. Therefore no visitor implementation can be used to implement logic based on the collected results of a traversal.


          PROPOSAL:
          ========
          Addition of a method PicoVisitor.traverse(Object). This method will initiate the traversal and call the objects accept method. Call

          visitor.traverse(pico);

          instead of

          pico.accept(visitor);


          BENEFITS:
          ========
          - The LifecycleVisitor depends on a exact reversal of the visited components. Therefore the PV.isReverseTraversal method was introduced. Unfortunately this makes the node's implementation responsible for the evaluation of the visitors traversal mode and forces all nodes with a composition pattern to implement a reverse traversal (see also number of calls to isReverseTraversal in http://www.picocontainer.org/versions/1.1-beta-2/clover/org/picocontainer/defaults/LifecycleVisitor.html). The proposed API would allow the implementation of a ReversalVisitor, that records all visits and execute them in reverse order on a delegated visitor later on. This would result in a clean implementation of all visit methods and allow the removal of isReverseTraversal at all.
          - The VerifyingVisitor could be enhanced. Currently it can only collect the exceptions verifying the CAs of one PC only (very similar to the old PC.verify behaviour), but with PV.traverse it could collect all exceptions of the complete hierarchy. Additionally the implementation can use a Map for the already verified components to prevent multiple verifications (PICO-166).
          SITUATION:
          ========

          The current PicoVisitor realization is based on stateless implementations only. This is caused by the fact, that the traversal is started from a node's accept method and the visitor cannot really know, what is the first and what is the last visit of the traversal. Therefore no visitor implementation can be used to implement logic based on the collected results of a traversal.


          PROPOSAL:
          ========

          Addition of a method PicoVisitor.traverse(Object). This method will initiate the traversal and call the objects accept method. Call

          visitor.traverse(pico);

          instead of

          pico.accept(visitor);


          BENEFITS:
          ========

          - The LifecycleVisitor depends on a exact reversal of the visited components. Therefore the PV.isReverseTraversal method was introduced. Unfortunately this makes the node's implementation responsible for the evaluation of the visitors traversal mode and forces all nodes with a composition pattern to implement a reverse traversal (see also number of calls to isReverseTraversal in http://www.picocontainer.org/versions/1.1-beta-2/clover/org/picocontainer/defaults/LifecycleVisitor.html). The proposed API would allow the implementation of a ReversalVisitor, that records all visits and execute them in reverse order on a delegated visitor later on. This would result in a clean implementation of all accept methods and allow the removal of isReverseTraversal at all.

          - The VerifyingVisitor could be enhanced. Currently it can only collect the exceptions verifying the CAs of one PC only (very similar to the old PC.verify behaviour), but with PV.traverse it could collect all exceptions of the complete hierarchy. Additionally the implementation can use a Map for the already verified components to prevent multiple verifications (PICO-166).
          Jörg Schaible made changes -
          Link This issue superseds PICO-166 [ PICO-166 ]
          Hide
          Paul Hammant added a comment -

          Sounds good. The exception collecting, perhaps, is design ahead of need

          Show
          Paul Hammant added a comment - Sounds good. The exception collecting, perhaps, is design ahead of need
          Hide
          Jörg Schaible added a comment -

          Done.

          Show
          Jörg Schaible added a comment - Done.
          Jörg Schaible made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]

            People

            • Assignee:
              Jörg Schaible
              Reporter:
              Jörg Schaible
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: