[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [34191]) replace monkey patch for `Catalog._getSortIndex` with a fake index that can sort search results according to their position in the container (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:63 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [34194]) replace `getObjPositionInParent` with stub index capable of sorting search results according to their position in the container, a.k.a. nogopip (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:64 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [34220]) migrate `getObjPositionInParent` to stub index capable of sorting search results according to their position in the container, a.k.a. nogopip (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:66 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [34078]) use our own zcml for testing also register the partial ordering adapter now that they [changeset:33504 get along with each other] (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:59 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [34154]) all those calls to `getObjectPosition` use adapter lookups etc, so introducing an optimization for the usual all results are from one folder case make sense (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:61 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [34156]) pull in the nogopip changes from [http://pypi.python.org/pypi/plone.app.folder plone.app.folder], which remove the `getObjPositionInParent` catalog index while keeping the possibility to sort by folder position (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:62 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [33924]) add `__getitem__` support to the default ordering adapter for optimized previous/next support in `plone.app.folder` (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:57 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [33931]) add adapter for previous/next support that doesn't need the catalog, or the `getObjPositionInParent` index for that matter (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:58 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [33870]) simplify calculation of the mapping from rid to position-in- parent make it work for results from different folders at the same time. the tests now work both with and without the nogopip patch (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:56 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [33790]) eek, that change ended up on the wrong (local git) branch — the monkey needs to be applied unconditionally, since `p.a.folder` doesn't get initialized in plone 4 (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:53 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [33792]) only do the extra sanity checks when running tests or in debug-mode (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:55 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Comment(by witsch): (In [30929]) add migration step for unified folders (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:48 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations
+---
Reporter: smcmahon|Owner: witsch
Type: PLIP| Status: closed
Priority: n/a |Milestone: 4.0
Component: Infrastructure | Resolution: fixed
Keywords: |
+---
Comment(by witsch):
(In [30898]) add results of running the benchmark tests with different
numbers of content items (5, 50, 500, 5000) and a helper script for
converting them into something mainly intended to be imported into a
spreadsheet app, but also slightly more human-readable (refs #9316)
to run the benchmarks yourself, you might use it like so::
{{{
$ bin/instance test -s plone.app.folder --tests-pattern=benchmarks 21 |
benchmarks/convert.py
}}}
--
Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:47
Plone http://plone.org
Plone Content Management System
___
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: closed Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: fixed Keywords: | +--- Changes (by witsch): * status: assigned = closed * resolution: = fixed Comment: the PLIP has been merged, and even though there are still [browser:buildouts/plone-coredev/branches/4.0/plips/plip9316-unified- folders@30539#l21 things left to wrap up polish] this ticket can be closed... -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:45 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: assigned Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by esteele): Please assist the doc team in creating/updating documentation relating to this PLIP. See #9615. -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:41 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: assigned Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by esteele): Your PLIP has passed the Framework team's initial review. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 30. -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:26 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: assigned Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Old description: ,,Copied from [http://plone.org/products/plone/roadmap/191/ PLIP #191] in the roadmap:,, = Unify folder implementations = ''We currently have Folder and Large Plone Folder implementations. [[br]] There should be only one.'' Proposed by:: Martin Aspeli Seconded by:: Andreas Zeidler Proposal type:: Architecture Repository branch:: [browser:plone.folder], [browser:plone.app.folder] == Motivation == Shipping with two folder types is unnecessary for several reasons: - It forces the user to make an a-priori choice about the number of objects they plan to put into a folder - We ship with the Large type disabled by default to avoid UI confusion - We don't have a proper search-based UI for large folders anyway Also the standard Folder type stores attributes, and has a single list _objects tuple which keeps the list of objects and order. This is prone to ConflictErrors and is slower. In simple benchmarks, a BTree-based folder performs orders of magnitude faster than a basic folder. == Proposal == Have a single folder implementation. - The internal storage is BTrees - It still supports ordering, by storing a separate sort order list/tree - It has at least two views - one search-based for large folders, one batch-based for small folders. This is either just a display menu choice, or a choice in the object's schema. Explicit sorting may be turned off for large folders. == Implementation == The package `plone.folder` in the Plone SVN provides a base implementation of a folder base class, which is not Archetypes specific, based on BTreeFolder2, but adding ordering. The exact ordering implementation is left up to an adapter, with a default providing explicit ordering. This allows other implementations, such as auto- sorting based on some key. The diagram below shows the folderish base- and mix-in classes used in OFS, CMF, Archetypes and Plone. Count 'em: [[Image(http://plone.org/products/plone/roadmap/191/Folder%20mess.png)]] The new base class from `plone.folder`, i.e. `OrderedBTreeFolderBase`, is used by `plone.app.folder` to provide two folderish classes, one targeted to `Archetypes` (`BaseBTreeFolder`) as well as one for `ATContentTypes` (`ATFolder`). Both add relatively little extra code and setup in order to make them fully compatible with the original, to be replaced classes. The package also provides a `GenericSetup` profile replacing the standard Folder content type with the new one. In-place migration will convert the internal data-structures when upgrading to use the new folders. Such migration code (including thorough tests) already exists in a project- specific package, and just needs to be moved into `plone.folder` itself. The migration runs relatively fast |---| in several performance tests about 13,000 folders holding some 200,000 items in total were migrated in about 5 minutes. .. |---| unicode:: U+2014 .. em dash The Container type in `plone.app.content` does not use BTrees, nor does it support ordering. Rather than changing this class and providing migration, we could add a new type, e.g. called `OrderedContainer` or just `Folder` (to signify closer resemblance to the standard folder behaviour) that mixes in the new class instead of `PortalFolder`. In addition, `plone.folder` also provides an ordering adapter, which only considers certain content to be orderable (implemented via marker interfaces). This allows for ordering of content that requires it, for example navigational items, without any added performance penalties if those share a folder with other, non-orderable content in large quantities. == Deliverables == - New folderish base classes that are BTree-based and support large content sets as well as ordering. - Improved `Products.ATContentTypes.content.ATFolder` and `Products.ATContentTypes.content.ATBTreeFolder` versions which use BTrees and supports ordering. - New class plone.app.content.container.Folder (?) that uses BTrees and supports ordering. - The ability to switch to a folder view/behaviour that's optimised for large content sets. - In-place Migration for all existing sites. == Risks == - There may be migration issues involved for derived folderish types with additional data-structures regarding containment and/or ordering. - This vision makes the existing `BaseBTreeFolder` in Archetypes orderable (though in some UI configurations you may not see the ordering, to prevent the user invoking
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: assigned Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by witsch): (In [29060]) add [http://pypi.python.org/pypi/plone.app.folder plone.app.folder] as a dependency to `Plone` update the FTI for Folder content to use the new implementation (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:23 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: assigned Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by witsch): (In [29061]) add review notes for PLIP #9316 (refs #9316) -- Ticket URL: http://dev.plone.org/plone/ticket/9316#comment:24 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: assigned Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Old description: ''Copied from [http://plone.org/products/plone/roadmap/191/ PLIP #191] in the roadmap:'' = Unify folder implementations = '''We currently have Folder and Large Plone Folder implementations. There should be only one.''' Proposed by:: Martin Aspeli Seconded by:: Andreas Zeidler Proposal type:: Architecture Repository branch:: [browser:plone.folder], [browser:plone.app.folder] '''Motivation''' Shipping with two folder types is unnecessary for several reasons: - It forces the user to make an a-priori choice about the number of objects they plan to put into a folder - We ship with the Large type disabled by default to avoid UI confusion - We don't have a proper search-based UI for large folders anyway Also the standard Folder type stores attributes, and has a single list _objects tuple which keeps the list of objects and order. This is prone to ConflictErrors and is slower. In simple benchmarks, a BTree-based folder performs orders of magnitude faster than a basic folder. '''Proposal''' Have a single folder implementation. - The internal storage is BTrees - It still supports ordering, by storing a separate sort order list/tree - It has at least two views - one search-based for large folders, one batch-based for small folders. This is either just a display menu choice, or a choice in the object's schema. Explicit sorting may be turned off for large folders. '''Implementation''' The package `plone.folder` in the Plone SVN provides a base implementation of a folder base class, which is not Archetypes specific, based on BTreeFolder2, but adding ordering. The exact ordering implementation is left up to an adapter, with a default providing explicit ordering. This allows other implementations, such as auto- sorting based on some key. The diagram below shows the folderish base- and mix-in classes used in OFS, CMF, Archetypes and Plone. Count 'em: Folder inheritance:img:Folder%20mess.png An initial investigation suggests that this could be made a base class for BaseBTreeFolder in Archetypes. This is backwards compatible, since the new type simply replaces the rather simple CMFBTreeFolder. We'd then need to make this folder type the default, and ensure that there's adequate migration (either in that existing instances continue to work but new folders have this feature, maybe with an optional migrate action, or through some mass migration). The Container type in plone.app.content does not use BTrees, nor does it support ordering. Rather than changing this class and providing migration, we could add a new type, e.g. called OrderedContainer or just Folder (to signify closer resemblance to the standard folder behaviour) that mixes in the new class instead of PortalFolder. '''Deliverables''' - Improved Products.ATContentTypes.content.ATBTreeFolder that uses BTrees and supports ordering. - New class plone.app.content.container.Folder (?) that uses BTrees and supports ordering. - An out-of-the-box Folder type that is BTree-based and supports large content sets as well as ordering. - The ability to switch to a folder view/behaviour that's optimised for large content sets. - Migration/graceful fallback for all existing sites. '''Risks''' - There may be non-trivial migration involved if existing instances should be changed. - This vision makes the existing BaseBTreeFolder in Archetypes orderable (though in some UI configurations you may not see the ordering, to prevent the user invoking slow operations), which may be unexpected '''Progress''' Complete: - Create a base folder implementation - OrderedBTreeFolderBase - Hook this into BaseBTreeFolder in Archetypes - Fix CMFPlone so that it detects the order support based on a Zope 3 interface rather than a Zope 2 one - Test that order support works on the new folder - Switch FTIs and portal_type's around so that the default Folder portal_type is a btree-based folder - Enable next/previous navigation for this folder type - Enable photo-album support for this folder type - Enable archiving support for this folder type - Enable ordering policy to be specified by adapter To-do - ATContentTypes: - Fix remaining ATCT and CMFPlone test failures (mainly around WebDAV) - Write migrations for FTI and portal_type changes - Provide optional migration to change types in-place To-do - plone.app.content: - Create new Folder base class, using the new mixin, with tests '''Benchmark results'''
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: assigned Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Old description: ,,Copied from [http://plone.org/products/plone/roadmap/191/ PLIP #191] in the roadmap:,, = Unify folder implementations = ''We currently have Folder and Large Plone Folder implementations. [[br]] There should be only one.'' Proposed by:: Martin Aspeli Seconded by:: Andreas Zeidler Proposal type:: Architecture Repository branch:: [browser:plone.folder], [browser:plone.app.folder] == Motivation == Shipping with two folder types is unnecessary for several reasons: - It forces the user to make an a-priori choice about the number of objects they plan to put into a folder - We ship with the Large type disabled by default to avoid UI confusion - We don't have a proper search-based UI for large folders anyway Also the standard Folder type stores attributes, and has a single list _objects tuple which keeps the list of objects and order. This is prone to ConflictErrors and is slower. In simple benchmarks, a BTree-based folder performs orders of magnitude faster than a basic folder. == Proposal == Have a single folder implementation. - The internal storage is BTrees - It still supports ordering, by storing a separate sort order list/tree - It has at least two views - one search-based for large folders, one batch-based for small folders. This is either just a display menu choice, or a choice in the object's schema. Explicit sorting may be turned off for large folders. == Implementation == The package `plone.folder` in the Plone SVN provides a base implementation of a folder base class, which is not Archetypes specific, based on BTreeFolder2, but adding ordering. The exact ordering implementation is left up to an adapter, with a default providing explicit ordering. This allows other implementations, such as auto- sorting based on some key. The diagram below shows the folderish base- and mix-in classes used in OFS, CMF, Archetypes and Plone. Count 'em: [[Image(http://plone.org/products/plone/roadmap/191/Folder%20mess.png)]] The new base class from `plone.folder`, i.e. `OrderedBTreeFolderBase`, is used by `plone.app.folder` to provide two folderish classes, one targeted to `Archetypes` (`BaseBTreeFolder`) as well as one for `ATContentTypes` (`ATFolder`). Both add relatively little extra code and setup in order to make them fully compatible with the original, to be replaced classes. The package also provides a `GenericSetup` profile replacing the standard Folder content type with the new one. In-place migration will convert the internal data-structures when upgrading to use the new folders. Such migration code (including thorough tests) already exists in a project- specific package, and just needs to be moved into `plone.folder` itself. The migration runs relatively fast |---| in several performance tests about 13,000 folders holding some 200,000 items in total were migrated in about 5 minutes. .. |---| unicode:: U+2014 .. em dash The Container type in `plone.app.content` does not use BTrees, nor does it support ordering. Rather than changing this class and providing migration, we could add a new type, e.g. called `OrderedContainer` or just `Folder` (to signify closer resemblance to the standard folder behaviour) that mixes in the new class instead of `PortalFolder`. In addition, `plone.folder` also provides an ordering adapter, which only considers certain content to be orderable (implemented via marker interfaces). This allows for ordering of content that requires it, for example navigational items, without any added performance penalties if those share a folder with other, non-orderable content in large quantities. == Deliverables == - New folderish base classes that are BTree-based and support large content sets as well as ordering. - Improved `Products.ATContentTypes.content.ATFolder` and `Products.ATContentTypes.content.ATBTreeFolder` versions which use BTrees and supports ordering. - New class plone.app.content.container.Folder (?) that uses BTrees and supports ordering. - The ability to switch to a folder view/behaviour that's optimised for large content sets. - In-place Migration for all existing sites. == Risks == - There may be migration issues involved for derived folderish types with additional data-structures regarding containment and/or ordering. - This vision makes the existing `BaseBTreeFolder` in Archetypes orderable (though in some UI configurations you may not see the ordering, to prevent the user invoking
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: assigned Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by esteele): Approved by FWT vote. -- Ticket URL: https://dev.plone.org/plone/ticket/9316#comment:18 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9316: Unify folder implementations
#9316: Unify folder implementations +--- Reporter: smcmahon|Owner: witsch Type: PLIP| Status: assigned Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by calvinhp): FWT Vote: +1 -- Ticket URL: https://dev.plone.org/old/plone/ticket/9316#comment:15 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
