On 1/31/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] schrieb:
> > 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.
>
> Would a parent-child
> relation still require explicit assignment, or would it be determined
> based on keywords, groups etc.?
(Assuming a flat document storage and many of my other ideas)
The parent-child relationship is determined by the ParentUNID property
on the child document. Children know their parent. To avoid having to
update the parent when a child is created or moved (or searching the
entire datastore everytime a parent needs the children), there is a
special table containing only "childUNID - parentUNID". The child
registers itself, then the parent reverses the lookup for
getAllPrimaryChildren().
If we want to support multiple parents, we need another of these
tables for getAllChildren(). Add a third column if you want to label
the child groups: getAllChildren(grouplabel), but that also requires
more data in Document:
<Document id="myPage" unid="xxx1" parentunid="aaa1">
<AlternateParent unid="aaa2"/>
<AlternateParent unid="aaa3" grouplabel="myAlternateGouping"/>
...
</Document>
getParentUNID returns "aaa1"
getAllParents() returns "aaa1", "aaa2", "aaa3"
getAllParents("myAlternateGrouping") returns "aaa3"
This document is returned in the list by:
aaa1.getPrimaryChildren()
aaa1.getAllChildren();
aaa2.getAllChildren();
aaa3.getAllChildren();
aaa3.getAllChildren("myAlternateGrouping");
The hierarchical indexes use this table to build the tree. They can
still have filters (selection formulas) and sorts. An index could be
defined:
Name: BlogsLastCreatedFirst
Type: Hierarchical
Filter: DocType = "Blog"
Sort: Reverse CreatedDate (latest at top)
A Module or Navigation Element then uses this index. I would
implement it by replacing:
<map:generate src="pubs/{1}/content/{2}/sitetree.xml"/>
With:
<map:generate type="sitetree" publication="{1}"
index="BlogsLastCreatedFirst"/>
which returns XML looking like 1.2's sitetreee.xml. The difference is
the flexibility. Change the index name and it returns a completely
different set of Documents. If the "index" property is missing, it
uses the default Index for the pub. If the "publication" property is
missing, it uses the default pub for the Lenya server.
The indexes should be easily configurable. The default hierarchical
index should always be created. Others could be defined by the
publication or modules:
<index name="xxx" type="hierarchical|flat">
<filter property="type">XHTML|Blog</filter>
<sort property="createdDate" priority="1"/>
<sort property="title" priority="2"/>
</index>
XML for the filters needs work to make it more flexible,
understandable, and implementable. Most indexes will be configured by
developers for use by Modules. Users just add the Module and the rest
is magic.
For performance, it would be good if the publication checks the
existing Indexes when adding a new one. If the definition already
exists, then the new Index's name is added as an alias for the
existing Index. Example: The "RSS" module uses the Index "RSS", but
the definition matches an existing Index "LastCreatedFirst". This
allows Modules to name their Indexes with the Module name, without
creating and maintaining duplicate Indexes.
===
> How would the editor create a certain URL space?
Each child can build its own URLs.
function String Document.getPrimaryURL(){
newurl = getID();
parentUNID = getParentUNID();
while(parentUNID){
document = getDocumentByUNID(parentUNID);
newurl = document.getID() + "/" + newurl;
parentUNID = document.getParentUNID();
}
return newurl;
}
* If we use "multiple parents" then build them all:
ParentUNID = "aaa"
AlternateParentUNIDs = "bbb", "ccc"
function URLList getAllURLs(){
URLList allURLs = new URLList(); //URLList is a HashMap?
foreach parentUNID in ParentUNID:AlternateParentUNIDs{
parent = getDocumentByUNID(parentUNID);
parentURLs = parent.getAllURLs();
allURLs = each string in parentURLs + "/" + getID();
}
}
// Get the closest match for the current situation:
function int matchScore(url1, url2) = lower is better match.
function String getClosestURL(String url){
URLList urls = getAllURLs();
retURL = urls.next();
score = matchScore(url, nextURL)
foreach testURL in urls{
tmpScore = matchScore(url, nextURL)
if(tempScore < score){
retURL = testURL;
score = tmpScore;
}
}
}
Any mistakes are because I just woke up.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
