Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1-1-beta-2
-
Fix Version/s: 1.1
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Number of attachments :
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
- supercedes
-
PICO-166 Verification needs "thinking/optimize"
Activity
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 ( |
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 ( |
Jörg Schaible
made changes -
Jörg Schaible
made changes -
Status | Open [ 1 ] | Closed [ 6 ] |
Resolution | Fixed [ 1 ] |
Corrected description.