[Framework-Team] Final decision on PLIP 9327 (Unified interface for lists of content)

Laurence Rowe l at lrowe.co.uk
Fri Jan 21 22:14:06 UTC 2011


On 21 January 2011 17:54, Ross Patterson <me at rpatterson.net> wrote:
> Alec Mitchell <alecpm at gmail.com> writes:
>
>> On Fri, Jan 21, 2011 at 6:52 AM, Geir Bækholt <plone at baekholt.com> wrote:
>>> On 20-01-2011 16:57, Eric Steele wrote:
>>>>
>>>> I'd like to get a final consensus on whether or not PLIP 9327 will be
>>>> included in 4.1. From discussion last week, several of you wanted to hold
>>>> out until we knew whether collections and search results would be in. At
>>
>>>> this point, it looks like those two will be pushed off for 4.2.
>>>>
>>>> With 5 of 8 votes in, it stands at a +4 for inclusion. Are there any
>>>> objections to my considering it approved?
>>>
>>>
>>> I was told to prioritise documentation, but i'll be happy to convert default
>>> listing templates or portlets to use it.
>>>
>>>
>>> One of the more important cases with contentlisting is to make it easier to
>>> start using it as an integrator and that addons can depend on it. For that
>>> is important that it is included, not an addon.
>>
>> That sounds like framework proliferation to me.  If an addon wants to
>> use this API then they can add it as a dependency; that's not a huge
>> burden after all.  If either the search improvements or the
>> collections were ready, then we'd at least be providing some examples
>> of how to use the library in Plone and some indication that it was a
>> recommended API.  As it is, it just seems to add further confusion to
>> Plone's developer/integrator story.
>
> Agreed.
>
>> The PLIP had explicitly removed conversion of the templates as a goal.
>>  Also, it's not entirely clear whether such a conversion would be
>> appropriate for a 4.x release, since such changes could break
>> customizations which rely on the macros, etc. from the current
>> implementation.
>
> Also, agreed.

I agree with the first point (code should only declare a setup.py
requirement when it actually uses it), but I would like to see
folder_contents change to use this in a future 4.x release - It would
be good to use it with an uncatalogued folderish object, e.g. a folder
returning items from a database query.

Laurence



More information about the Framework-Team mailing list