#97: Allow the "display" menu to work on portal root

Being able to set the default view (e.g. a new listing, a folder listing, a welcome page, etc.) of the portal in a consistent, easily accessible way is a common requirement for a very common use case.

With the implementation of PLIP78, an interface IBrowserDefault, and a sub-interface ISelectableBrowserDefault was added to Plone. An implementation of this interface was added to ATContentTypes, in BrowserDefaultMixin, which delegates to Archetypes' TemplateMixin. TemplateMixin in turn uses a registry of types-to-available-templates in archetypes_tool.

Obviously, the ATContentTypes and Archetypes part of that equation is inappropriate for the portal root, but there is no reason why Portal.py can't implement the interface itself.

As for registration of templates, a simple property on the portal root object should suffice. The generalised type-to-template mapping available to third party products is already provided by the framework used to create third-party types (that is, Archetypes, possibly with ATContentTypes for base classes). The portal root is conceptually a special case anyway, and should probably not automatically get any third-party templates registered for folders. A ZMI property is more accessible to those who want to write their own page templates and use as the front page (also a pretty common use case).

A quick look at Portal.py suggests that we could:

• Let PloneSite implement ISelectableBrowserDefault
• Add a lines property portal_front_page_templates to the portal root, holding the available views
• Implement the methods of the ISelectableBrowserDefault interface to look at this property for the vocabulary of available templates, and store the currently selected template in a variable on the portal object[1]. In particular, note that the lookup methods here actually delegate to browserDefault() in plone_utils, leaving all the logic in one place.
• Change the default creation of an index_html file in the portal root to a document called welcome-to-plone and set this as the default front page upon portal creation. This is because the index_html mechanism overrides the IBrowserDefault mechanism, being a lower-level Zope concept. Also, when people have an explicit index_html set and upgrade, we don't want to override their settings magically. The effects on the end user of this change will simply be that their front-page docuent has a more sensible name. Existing uses of index_html will not be affected at all.

[1] Note that in the ATContentTypes BrowserDefaultMixin, the variable storing the current selected default page is a property called default_page. This makes the mechanism consistent with the previously encouraged behaviour of setting a property default_page at the folder level to select a default page for that folder, and adds the UI of the display menu. However, for the portal root, the meaning of this property is overloaded rather unfortunately to mean "ids of objects to globally consider as the default page", essentially permitting different "magic" ids analogous to index_html. As such, we can't use this property for storing the default page on the portal root. This is actually quite unproblematic, the choice of using this in ATContentTypes' BrowserDefaultMixin was simply as a convenience to those who had already been doing this at the folder level. The use of default_page at the portal root is encapsulated in portal_utils.browserDefault() and will continue to work as expected.

• A display drop-down at the portal root consistent with the one found on folders currently.
• Unit tests for the new methods of the PloneSite object.

The implementation should, as far as can be predicted, should be unobtrusive and not alter any existing behaviour. The existing 'default_page' and 'index_html' mechanisms on the portal root will continue to work unaffected, but when no 'index_html' is present, the user will be able to select a default view template or object to use as the front page in a manner consistent with the way this is now done for folders.

Work completed on branch uiteam-plip97-root-display-menu.

Note that a small change in ATCotnentTypes is necessary after merging this branch, because its implementation of the ISelectableBrowserDefault interface used to return a DisplayList for getAvailableLayouts(), which is AT-only. It should return a list-of-tuples, which the interface now stipulates stronger. The uiteam-plip97-root-display-menu branc of ATContentTypes has these changes, and should be merged simultaneously with the Plone branch.