[EMAIL PROTECTED] schrieb:
[...]
Adding to this:
1. visibility in terms of accessibility through the URL space (Published)
2. visibility in terms of appearance in navigation widgets (In an Index)
3. other widgets (A Website Map should be able to show documents that
are not in the menus. Does it use another Index, or are there levels
of visibility?)
The website map could use another navigation (structure):
- Structures
- Structure "menu"
- StructureNode "foo" [EMAIL PROTECTED] = false]
- Structure "map"
- StructureNode "foo" [EMAIL PROTECTED] = true]
4. Security (even if it is "visible" in a menu, it only appears if you
have access to it.)
How will #2 be implemented?
A. Does an Index use a formula for selection (View)?
B. Must the documents be manually added to the Index (Folder)?
That's up to the implementation. The repo draft API declares getter
and setter methods, but I could imagine specific implementations
that support only getters, which are backed up by an algorithm
(e.g., return all pages sorted alphabetically by page title).
View Indexes are updated when used. Visibility is determined by
whether a Document meets the Selection Formula, which could use a
"Visibility" property: "if doctype is XHTML and visibility = true".
They can be updated "every request", "every request if last update was
over an hour ago", "serve request from current index, but update in
background if needed", "scheduled updates in background". Views can
rebuild themselves from the Document store, but the indexing can be
intensive when there are many Documents.
How would the editor create a certain URL space? Would a parent-child
relation still require explicit assignment, or would it be determined
based on keywords, groups etc.?
[...]
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
