In applying the patches, I mostly stuck to the stated purpose of the original filing, which was to reduce the need to pack/unpack collections of WikiPages and the like by using narrower Collection return types. New methods for sorting are just that, new methods; it wasn't clear to me you wanted to add features in addition to just optimizing.
What is the use case you have in mind? It it's just name order than you need, you can just call filterCollection() and then Collections.sort() on the returned collection because WikiPage implements Comparable<WikiPage>, the default implementation of which sorts by name. Collections.sort( Comparator) would allow other orders. Andrew On Mon, May 11, 2009 at 3:20 AM, Greg Kable <[email protected]> wrote: >> Andrew Jaquith commented on JSPWIKI-528: >> ---------------------------------------- >> Also, I chose a different idiom for the method signatures >> that indicate when Lists should be sorted. Instead of >> creating a method ContentManager.getAllPagesSorted( >> String space ) as suggested in the patch, I created an >> alternate method getAllPages(String,Comparator<WikiPage>) >> that makes the sort request explicit (via the Comparator) >> and is also customizable. In addition, to allowed returned >> Lists to be sorted simply using Collections,sort(), WikiPage >> now extends Comparable<WikiPage>, as does JCRWikiPage. > > Just spotted a problem... > > Since my patches add multiple ways of sorting pages, including a plugin > parameter, the logical place to do that is in AbstractFilteredPlugin. If > it's not done there, we'll end up with a ton of cut and paste code to find > and use the correct comparator. > > Does anybody have any objection to me adding a filterAndSortCollection > method to AbstractFilteredPlugin? > > Thanks, > Greg >
