[Plone-UI] Folderish Page Proposal

[David Glick (Plone)]

On 10/5/13 5:50 PM, Rob Gietema wrote:
> Hi UI-team,
>
> During the Conference sprint we had a discussion about pages being 
> folderish or not by default. We all liked the idea but were not sure 
> if it would work well with items as default view. After a brainstorm 
> the idea came up of getting rid completely of this feature. The 
> solution is to get rid of the "Collection"-type and add that 
> functionality to a page.
>
> I've attached some screenshots to make the idea a bit more clear. The 
> first screenshot shows a page where the display menu is removed 
> completely and from the add menu the "Collection" is removed.
>
> The second screenshot shows an extra tab when editing a page called 
> "Display". The display  tab contains a field called "View". The user 
> can select the views like "Standard", "Listing", "Summary" etc. The 
> "Standard"-view will only show the page content like you would expect 
> and hide the fields underneath in the screenshot. If you select any 
> other view containing some form of listing you will get the fields in 
> the screenshot. By default the selection criteria is "Location -> 
> Relative Path -> ." so all items in the current folder will be 
> displayed. And the order will be "Order in Parent". This way the 
> listing views will behave the same as they do now. If users want to 
> change the criteria to show other items or change the ordering (for 
> example order by date reverse for events/news items) you can change 
> this here.
>
> This proposal will simplify the ui a lot by getting rid of the display 
> menu, the select item as default view and collections as a type. Let 
> us have a discussion whether or not this proposal covers all usecases 
> or not.
>
I think this is an interesting proposal worth considering. One of the 
options on the enhanced Display tab could be "Custom view (advanced)" so 
that you could type the name of a view or template there when you need a 
special one, rather than jumping to the ZMI properties tab.

I actually set out writing this email to list all the problems this 
proposal leaves unanswered, but I'm having more trouble than I expected 
coming up with significant objections.

The biggest downsides are:
- Addons need to change their types to be folderish and migrate existing 
content. This can perhaps be avoided if we change common base classes 
and make plone.folder smart enough to set up folder internals (_tree, 
_count, _mt_index and the order annotation) lazily.
- Non-structural folders (i.e using object containment and Plone's 
contents tab for purposes other than navigation) can no longer be used. 
This is mitigated somewhat if we continue improving our data grid widget 
so there's a good alternative to migrate to.
- The need for a tricky migration that turns the current default page 
structure (content item X inside folderish item Y) into the new (X 
containing the old contents of Y)
- What do we do with custom content types that are folderish and have 
default pages? We can't just replace the container in this case like we 
can with standard folders, because we would lose custom fields on the 
container. For that matter, even a standard folder may have custom 
fields added by schema extenders or behaviors.

A variation on this proposal would be for the content listing to be 
something that gets enabled to show below the content-core of an item, 
rather than replacing the content-core. This way you can use it for 
things other than Pages too.