Bug 43989 - define a consistent sitemap API for all modules that operate on documents
Summary: define a consistent sitemap API for all modules that operate on documents
Status: NEW
Alias: None
Product: Lenya
Classification: Unclassified
Component: Miscellaneous (show other bugs)
Version: Trunk
Hardware: Other other
: P2 enhancement
Target Milestone: 2.0.1
Assignee: Lenya Developers
Depends on:
Reported: 2007-11-29 02:37 UTC by J
Modified: 2007-11-29 03:37 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description J 2007-11-29 02:37:33 UTC
currently, each module that operates on documents has it's own way of addressing
them - some use context information from the page envelope, some have
parameterized matchers, but they are often inconsistent.

i propose the following contract between modules that operate on documents and
the rest of the world:

any such module must provide

* a context-insensitive (fully parameterized) entry point that operates on the
document path
* a context-insensitive entry point that operates on a UUID plus optional
language and revision.

a module can provide
* a context-sensitive entry point that operates on the current document via the

all those entry points should be accessible via standardized matcher patterns.

andreas points out that the matching of document path to UUID can be factored
out and handled by the global sitemap, where /modules/** requests are matched.
Comment 1 solprovider 2007-11-29 03:37:11 UTC
See 1.3 Help:

The second half of this file defines the content: protocol used in Lenya 1.3. 
This protocol does everything anybody could possibly desire for retrieving
documents.  Lenya 1.3's content resources:
- include all types of data: text, xml, and binary files/records.
- are accessible by uuid/unid or path.
- can specify language.
- can specify revision.

These specifications should be able to replace all local data access methods.

The protocol is implemented by the o.a.l.cms.content packages.  The current
packages handle 1.2's hierarchical data structure and 1.3's flat data structure.
 Can this code be ported to 2.0 with a new package for 2.0's structure?