Zope 3 wiki → Documentation → HistoricalDocuments →
last edited 4 years ago by evan
created: 2003-08-03

PublishFolders

Publish Folders

Allow a browser user to give a URL to a folder and let the folder manager to control what they see when they do. This doesn't seem to affect any other users (type of access). For example, this doesn't make sense for FTP or WebDAV?.

The component model should certainly allow this, and can facilitate it in a minor way.

When you visit a folder served by Apache: 

    http://someserver/folderx/foldery

Apache sees that you've accessed a folder and redirects you to a URL with a slash added: 

    http://someserver/folderx/foldery/

Apache satisfies this URL by returning the content of a default page, like index.html.

ZPublisher? currently does something similar, but without a redirect. It changes a URL like: 

    http://someserver/folderx/foldery

or: 

    http://someserver/folderx/foldery/

to: 

    http://someserver/folderx/foldery/index_html

internally. It also adds a base tag to adjust for the URL change. ZPublisher? does this for any object, not just a folder, that has an index_html.

ZPublisher? provides the bonus that index_html can be acquired.

There are a number of problems with ZPublisher?'s approach:

  • If an object doesn't want to be browser accessible, it must use explicit acquisition or provide a null index_html. It's harder than it should be for an object to opt out.
  • If an object wants to provide a browser interface, it must provide an index_html or it must use explicit acquisition and provide a dedicated __call__ method. This forces us to add web-specific logic to content objects.
  • ZPublisher? makes no distinction between content and presentation. Acquisiition makes sense for controling presentation. It is reasonable to provide a presenatation for a folder and have it apply to sub-folders.

    If index_html is used for (default) content, then acquisition makes a lot less sense.

  • Of course, the core problem is that the policy for displaying folders is hard-coded in the publisher.

The solution is to put the control of the default content and/or view in the hands of the folder manager, rather than hard code it in the publisher. The UI for this is outside the scope of the component model.

There should be an API that the publisher uses to decide if and what to publish beyond what is provided by the URL. The poposed API is as follows. When the publisher has traversed a URL, it will check for, and, if present, call the following method on the object resultiung from traversal:

__browser_default__(request)
This method returns two values:
  1. An object that replaces the object already reached through traversal. This may be the same object.
  2. A sequence of names to be added to the URL path. If this sequence is non-empty, then:
    • The logical URL will be extended
    • A base href will be used to reflect the logical URL.
    • Traversal will continue using the new path components. Of course, when the additional traversal completes, we will not call __browser_default__ again.

Additional notes

The following notes aren't particularly relevent to thye component model, but are worth capturing.

  • An improved folder UI should provide three knobs:
    1. A list of ids to check for default content. Content is not acquired, so if the folder doesn't have one of these ids, it doesn't have default content. Of course, the list may be empty. It is also possible to specify that the list of default content names is acquired, which is the default. Maybe we even want to be able to augment the acquired list.
    2. A selection of ways to display the folder if there is no default content. The possible settings include raising NotFound? and showing a classic folder list. It will be possible to register multiple presentations for a folder. Each presentation will have a textual description for display in the selection list. IOW, the UI will not show "components", but will, instead, show textual descriptions, which map to components under the hood.
    3. An option to use an HTTP redirect rather than logical URL manipulation and base tag.
  • The publisher should be smart enough not to provide a base tag when the URL ends in / and only one step is added to the URL. In fact, maybe the publisher should not remove the trailing slash but should handle it at the default step.

evan (Aug 27, 2001 10:55 am; Comment #1) Editor Remark Requested
 >   (type of access). For example, this doesn't make sense for FTP or
 >   WebDAV.

I disagree. A Site Manager might well want to control which folders are visible to an FTP or WebDAV? user, in what hierarchy, and with only certain types exposed. A specialization of WebDAV? for visual HTML editors might only expose page template and DTML objects in skin folders, and even perform a transformation on their names (extensions).



( 93 subscribers )