Forgot your password?
New user?
Document Actions
#110: Un-hardwire site root (a.k.a. the subsite proposal)
- Proposed by
- Sidnei da Silva
- Proposal type
- Architecture
- State
- being-discussed
Motivation
- Having the content root being a subfolder of the Plone Site makes it easier to export, import and reindex content when needed.
- It's common for large sites to have multiple skins which represent different subsites of a bigger site. Instead of creating a Plone site for each such subsite and increasing maintenance burden it would be desirable to have the subsites share as much common infrastructure with the main site.
- Usually subsites share some content between them. This is easier to do and allows Archetypes References to be used between them. That is not trivial to do with multiple Plone sites.
- Though in such cases 'physically' the subsite is part of the main site, it is a requirement that making it look like it's a completely separate site doesn't take a rocket engineer. That means at the flick of a switch everything in the Plone UI (portlets, navigation tree, breadcrumbs) plus searches must be restricted to the subsite.
The issues above are more visible in the case of large, departamentalized organizations, educational institutions and 'NGOs' where each 'department' or 'section' needs it's own look-and-feel and adding a new department/section/subsite must happen quickly and with minimal effort.
Proposal
- An analisys of Plone source to identify places where there are assumptions on content being 'portal-wide' or the site root being the Plone Site object.
- Change those places to look for a marker interface on objects in the acquisition chain and use the path to this marked object for restricting catalog queries.
NOTE: This proposal doesn't contemplate the inclusion of a subsite implementation within Plone itself, but instead it proposes a marker interface for third-party subsite implementations and the behaviour of Plone's navigational elements when they find such a interface.
Implementation
The 'goldegg-phase-1' already has an implementation of a breadcrumbs view that behaves as described on this proposal. The next steps are the navigation tree and catalog queries for portlets and worklists.
Items that need attention
- Plone Tool (plone_utils)
- createTopLevelTabs [ ]
- createBreadcrumbs [X]
- createNavTree [ ]
- Catalog Tool (portal_catalog)
- searchResults/__call__ [ ]
- REQUEST (ZPublisher.HTTPRequest)
- physicalPathToURL [ ]
Food for Thought
- Should portal_url be a requirement for a subsite or should the portal_url tool be changed to comply with the same interface as proposed here for the other tools?
Proposed Implementation
NOTE: Some of the ideas here rely on acquisition for proper working. When the time comes to switch on to Five's sitemanager branch, we will instead explicitly pass a context attribute to the utility.
XXX Should we start passing a context attribute right now?
Catalog Tool
The idea here is that all places where the Catalog Tool is used acquire the Catalog Tool using getToolByName, so the subsite can be found by walking the acquired Catalog Tool aq_chain.
As soon as the subsite is found, we inject it's path as the path argument to the query to be executed, iff it doesn't already include one.
REQUEST
The physicalPathToURL method of the REQUEST object is used for translating a path to a URL based on some environment variables. In particular, it's used when translating a Catalog brain path to a URL on the brain's getURL() method.
The proposal is that the physicalPathToURL should lookup a mapping (generated by a catalog query and cached) of subsites to their public URLs. When physicalPathToURL is called, it will look at this mapping and inject the subsite URL as found on the mapping instead of teh current site URL found on the mapping instead of the one found in the environment.
Plone Tool
The methods listed there blindly assume that the 'site root' is the Plone Site itself. Instead of doing this, they should lookup containment for a folder with a marker interface that would be the 'subsite' and use it's path for building any structures needed for navigation.
As said above, the goldegg-phase-1 branch already contains some code and a refactoring of various methods of the Plone Tool to take a additional context argument.
In order to have more concrete goals, we could adopt the SubPlone project as the reference implementation of a subsite.
However, Plone and SubPlone would be knitted together only by interfaces. SubPlone would implement the interface that Plone would require in order to consider a ordinary container a subsite.
Any other folderish object that implemented (or adapted to) the same interface could be used as a subsite.
SubPlone is being used in several high-profile sites, along with some monkeypatching to implement the above suggested features in Plone 2.1.
Deliverables
- At worst, factoring out the exceedingly large methods in Plone Tool to use the CA (Component Architecture) views, adapters and utilities to abstract out implementations.
- Tests written for the abstractions created by this refactoring should be parametrizable so that external products which want to implement the same abstraction can reuse the tests by providing different implementations as a parameter to the test-to-be-run.
Risks
There is a risk that moving this feature into Plone would cause some extra bloat to the already bloated beast.
It's up for consideration of adding just the proposed interfaces and providing 'hook points' for external packages like SubPlone to implement those features instead. An example of such 'hook point' can be seen on the 'goldegg-phase-1' branch with the createBreadCrumbs implementation, that instead of inlining the whole implementation delegates to a view, which then does the dirty work.
In this case, the alternative view that looks up containment has been included in Plone as an example, along with another view that implements the original behaviour. They can be interchanged at will, and the tests for one must always run for both.
Progress log
Some of the proposed changes, mainly breadcrumbs, have been implemented in the 'goldegg-phase-1' branch as an example.
EnSimpleStaging
I was wondering how to do this while trying to use EnSimpleStaging ... this is one of the main things holding me back from really using that product and a dedicated content subfolder.
Which Plone version is this targeted for?
Zope 2.10 offers improved 'site' registration of behavior
clarify the split between SubPlone and Plone responsibilty here?
SubPlone currently has no mechanism for sub-rooting the site, it only takes over the skin. It's possible to use VHM and some hacks to the navigation code to get this semi-working, but tabs and breadcrumbs are still a pain. The navtree itself is definitely modular enough to handle this with any means of sub-rooting, and there is code in Plone 2.5 which is prepared to actively change the root based on a marker interface. It already, in fact, does this based on some other criteria, such as navigation properties.
I'd like to map this into a parallel roadmap item for SubPlone so that we can really take a look at making this happen.
Progress
I think this plip may be complete, not sure it needs to be set as being-discussed. I suppose we should make sure this behaviour is tested before calling it done, but, am I missing something?
I expressed some ideas on the plone-developers list recently wrt how the skins tool could possibly be more agreeable to this sort of setup, but that's probably meat for a whole new plip.
:)
(Sub-)domain
Every piece of content should not only know which skin has to be applied but even which (sub-)domain it belongs to in to avoid multiple URIs to the same content.
Lets do this differently
With these two I'm not sure this PLIP is still relevant.
I woudl love this
reco