incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Metske <harry.met...@gmail.com>
Subject Re: [jira] Commented: (JSPWIKI-528) Rationalise the use of Collections, particularly with regard to pages
Date Tue, 12 May 2009 15:59:43 GMT
+1 from me too



2009/5/12 Greg Kable <grackleflint@jspwiki.arbler.com>

> Andrew Jaquith wrote:
>
>> .... 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.
>>
>
> JSPWiki-528 was about refactoring.  This is for the 3.0 port of JSPWiki-526
> which adds new features and a new parameter to filtered plugins (sortorder).
>  The big issue is finding the right Comparator which really should be
> abstracted in to AbstractFilteredPlugin the same as filterCollection.
>
> Even if I didn't want AbstractFilteredPlugin to handle finding the
> Comparator, I also personally dislike cut-and-paste coding where everybody
> ends up writing the same four lines of code:
>
> getAllPages
> filterCollection
> findComparator
> sort
>
> This is such a common pattern in the Plugins that it really should be a
> separate API on the AbstractFilteredPlugin.
>
> regards,
>        Greg
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message