[
https://issues.apache.org/jira/browse/WICKET-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048588#comment-13048588
]
Pedro Santos commented on WICKET-3789:
--------------------------------------
+1
I like IVisitor because it is a very natural way of visiting children and
enable a good decoupling between callback and visiting logic. i.e. you can
place both in different classes and extend/reuse them.
But the majority of use cases are simple enough to demand a new type, and the
proposed idea address them nicely.
Why IteratorFilter#onFilter has the leaf parameter? Seems more natural to have
Component#isLeaf instead a polluted API for filters. Most of filters I saw in
the patch ignore this flag.
> visitChildren and friends require inner classes. Replace with iterators
> -----------------------------------------------------------------------
>
> Key: WICKET-3789
> URL: https://issues.apache.org/jira/browse/WICKET-3789
> Project: Wicket
> Issue Type: Improvement
> Reporter: Juergen Donnerstag
> Attachments: wicket-3789.patch
>
>
> I never really liked that we need inner classes (implementations of IVisitor)
> for traversing the component hierarchy. When needed, it comes easily to me
> that I need MarkupContainer.visitChildren(), but I always need to look up how
> to use it and friends. Debugging is also more complicated than it has to
> (breakpoint inside the visit function: either another breakpoint behind
> visitChildren or "press the continue-until-end-of-method" key several times
> until you are back). For these reasons I gave Iterators another try. I've
> attached a patch for others to review and provide feedback. I've also added
> test cases (ComponentIteratorTest) and I changed quite some visitChildren
> occassions in core. Maven compiles and successfully executes all tests.
> I put the new classes in org.apache.wicket.util.iterator
> ComponentIterator - An enhanced iterator with filters. Also supports chaining
> iterators. Builder API for class filters, isvisible filters, isenabled
> filters etc. Supports Java for each.
> ComponentHierarchyIterator - enhances ComponentIterator to provide hierarchy
> traversal. Adds traversal filters to separate traversal control from what
> next() returns. Same Builder API. Supports Java for each.
> IteratorFilter - Simple abstract class to implement the filter conditions.
> The Builder API makes use of it to add filters to the iterator.
> Some examples:
> ComponentHierarchyIterator iter = new ComponentHierarchyIterator(page);
> while (iter.hasNext())
> {
> Component component = iter.next();
> }
> for (Component component : new ComponentHierarchyIterator(page))
> {
> }
> new ComponentHierarchyIterator(page)
> .filterLeavesOnly()
> .filterByVisibility()
> .filterByClass(Form.class)
> iter.skipRemainingSiblings(); // skip all remaining component of the same
> parent
> iter.dontGoDeeper() // provided the current component is a container and
> potentially has children, they are ignored
> onEndOfSiblings() is a callback function if you want to be informed about the
> iterator leaving a level
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
