Solprovider Lenya Kongregate Registration for Free Flash Games and Chat with solprovider

Developer Mailing List 1

Hopefully this article will disappear soon as I merge it into other Suggestions. It is mostly sections of ML posts that did not fit into the new Glossary, but some of the information does belong on other Suggestions.


- The URL for Assets is based on the Publication. Usage could be as
simple as "/mypicture.gif" for the server's default pub, or
"/mypub/mypicture.gif" for other pubs. That would require the default
"live" Module checks extensions for handling. There are many possible
algorithms:
- - "live" retrieves the data;
- - "live" passes to "assets" which retrieves the data;
- - "live" passes to "assets" passes to "images" which retrieves the data.
Any of these options are easier than 1.2's Make Link "docid/assetname.ext".


An editor using the hierarchical view would enforce the integrity rules. It could also easily handle "Publish Subtree".

An editor using the flat view could publish Documents that are the children of an unpublished Document. Those Documents would show in the flat views, but would not appear in the hierarchical views until the parent is published. The flat view should support publishing multiple documents (using checkboxes), but the integrity rules are bypassed. One of the important flat views would be "Unpublished Documents" so people can see what is missing.

To create a new structure, "Create new hierarchy" that names the new Structure and allows the Documents to be moved without affecting the primary parent-child relationships. If the platform supports it, people will develop methods of using it eventually.

Every document has two URLs:
/pub/docunid (hopefully never seen by visitors)
/pub/primaryparentpath/docid

With multiple parents, alternates are allowed:
/pub/alternateparentpath/docid

The Document.getURL(contextURL) function allows finding the closest valid URL for this document based on the current context.

The tree used for selection is up to the editor module.

I would like Lenya-specific links to be XML links rather than specific URLs:
<link unid="xxx">text</link>
When the Document is retrieved, these are replaced using
Document.getClosestURL():
<a href=/pub/path/docid.ext>text</a>

With this, a document can be moved or accessed from different trees, but the links are automatically updated, and the URL displayed will be sensible.

I think the core platform should be extremely flexible as long as it extends the usefulness as a CMS. The functionality being discussed belongs in the core. It is easier to design for this functionality now rather than later. It should not add much complexity if implemented now; most of the code only needs a few lines to handle the additional functionality. And the additional flexibility will be very powerful as developers start using it.


=== Using Multiple Indexes vs. Using XSL on one Sitetree
Many examples are possible using XSL transformations on a massive sitetree. Most of the examples are much easier to implement, and much faster, if the platform supports multiple multiple indexes. The indexes would also support things that would be difficult without them, like security and flat views including documents without published parents.

This is about document storage and retrieval of a "sitetree".
This is not about the URLs. They can be decided from the context.
Example: Alternate hierarchy index "myView"
<map:generate type="sitetree" publication="{1}" index="myView"/>
The document selection and sorting is handled by the index. Then a "url" property could be added to each document entry based on the current context, either by the Sitetree Generator, or by XSL using the hierarchical relationship between the Document nodes (like the current system).


Document-based Databases (such as JCR) have many advantages over Relational (Table-based) Databases. Relational Databases can offer better performance, but that is rarely an issue today unless there will be millions of records/documents. For Lenya, we are moving to flat storage, which simulates Relational Database MUST do it, but we gain the flexibility that each node (Document) can have its own
fields/items/properties/children.

For the parent-child relations, children are added to the parent by adding a property (or multiple properties if multiple parents are allowed) to the child document. We could search the datastore for all the children that specify the same parent, but that function is used so often it is good to maintain/store the information separately for
performance. Yes, that could be a tuple, keying on either the parent or the child, possible selecting by a group name.


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?)
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)?

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.

Folder Indexes are updated when Documents are added. It is the developers' job to add the Document to all relevant Indexes. Folders store the list of Document UNIDs; a second list stores information such as access lists to each entry for performance. Visibility is determined based on the first list; if a document does not belong, it does not appear.

Folders are difficult for developers. Every document save must decide in which indexes this document belongs. The only real world use is email, where the user decides what belongs in each Folder. (And GMail avoids this by replacing Folders with Views that select on a multi-value "Label" field.)

The indexes should be easily configurable in Modules. The default hierarchical index is configured by the "live" Module. Most indexes will be configured by developers for use by Modules. Users just add the Module and the rest is magic.


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;
}


* For "multiple parents", 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;
}
}
}


<< IndexesNotes: Dev ML 2 >>

Contact Solprovider
Paul Ercolino