Giovanni Toffoli wrote:
> I always assumed that OrderedBaseFolder and BaseBTreeFolder are mutually
> exclusive.
they are in fact. `OrderedBaseFolder` derive from "regular" folders
(i.e. OFS.ObjectManager) and btree-based folders don't have support for
ordering their items ootb. in the typical use-case, i.e. a folder with
several thousands of objects, most of the time that's not desirable anyway.
the problem with that separation is that sometimes you cannot know in
advance how big your site's gonna grow. you might end up wanting
btree-folders with their performance benefits at some point (see the
charts in
http://plone.org/products/plone/roadmap/191). migration at
that point can be painful, though. otoh, starting out with
btree-folders right away prevents you from ordering your content, i.e.
in a folder listing or, more prominently, in the navigation.
> Looking for the possibility of overcoming said limitation, I've found this
> PLIP:
> #191: Unify folder implementations (2007-11-07)
>
http://plone.org/products/plone/roadmap/191the above said was motivation for this PLIP, of course. optional
ordering support for btree-based folders would give us "the best of
both", great performance and yet being able to sort with hopefully just
a little added overhead.
> It seems that much of the effort required to implement and benchmark it has
> already been done.
> But it is still in a "draft" state.
hmm, you're right. the code basically works and is already used in
several places, like dexterity for example. the PLIP's state should
probably be set to "proposed", but i guess nobody ever did that... :)
> PLIP #191 is being referred by another more recent PLIP, now
> "ready-for-merge" in Plone 3.3:
> #241: Clean up auto-sort, auto-order code (2009-01-25)
the story behind this is that we hit some obscure bbb issues when trying
to implement `plone.folder` as a drop-in replacement for regular folder,
i.e. with all tests from plone, archetypes and atcontenttypes passing.
that lead me to dive into some of the more long-standing code and
question it's motivation and present usefullness. one thing that jumped
at me was the commented out auto-sort code, which ultimately lead to
PLIP 241. other than that the PLIPs are not really related nor have any
dependencies code-wise.
> Moreover, both PLIPs are assigned to the same person: Andreas Zeidler.
yeah, i shouldn't have signed up for it... ;)
> Anybody knows whether
> - the implementation of PLIP 241 already encompasses the implementation of
> PLIP 191 ?
yes, i do: it certainly doesn't.
> - or there are plans to complete the implementation of PLIP 191 ?
there are. in fact, i'm working on it again these days (we're about to
use it in a production setting) and there'll be a first public release
very soon.
> Thank you in advance, Giovanni Toffoli
hth,
andi
ps: please cc me if you have more questions.
--
zeidler it consulting -
http://zitc.de/ -
[hidden email]
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at
http://zitc.de/pgp -
http://wwwkeys.de.pgp.net/plone 3.1.5.1 released! --
http://plone.org/products/plone/------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
Archetypes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/archetypes-users
