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

Restructuring Lenya

Lenya 1.4 is moving to JCR using Jackrabbit for its content repositiry. This provides a good time to restructure the architecture of document storage.

My suggestions are to:
1. Remove the Areas, keeping everything related to one document together. This is discussed in more detail in Use Area for XMAP.
2. Move to a flat structure.

I have always been critical of the "area" concept. In Lenya 1.2 terms, I would prefer:

There have been suggestions to move "language" even earlier in the path. As JCR, language could be either a node or a property. I cannot think of any reasons to have it as a node.

"versions" could be creation-time-based names for each revision "200512071751.xml", plus "index.xml" or "live.xml" for the currently published version. "archive" could prefix an "a". Trash could prefix a "d" (for about to be "deleted"). Publishing is simply overwriting "live.xml" with the desired revision.

The advantages are every revision of a document is in one place. The disadvantage was the live version would not be distinct in the file system, which was useful. That disadvantage does not apply when using Jackrabbit because file operations are very difficult.

In JCR terms, use properties for the revision nodes:
- status = "archived", "deleted", "active", "draft" (useful so someone else does not publish it before it is ready)
- created = {time}
- edited = {time of last edit}
- language (??)

There should also be a history (for each language) at the document node for which revisions were published and when. The document node should also specify which revision is the live one (unless that node is duplicated with a special identifier.)

Combining all this into the simplest structure (N=Node, P=Property, -=1, +=many):
+ N:DocumentID
- + N:SubdocumentID (same structure as DocumentID)
- - N:Document (extra node to ease distunguishing between the Document's Nodes and Nodes for the subdocuments.)
- - - P:Type (DocumentType = XHTML...)
- - - P:LiveRevision (for each language)
- - - P:Status = Draft, Review, Published, Version (published but another version is ready)
- - - P:Visibility
- - - P:Creator
- - - P:Languages Available
- - - P:{Other document properties}
- - - N:History of publishing for each language
- - + N:Revision
- - - - P:Status
- - - - P:Language
- - - - P:Editor
- - - - P:{Other revision properties}
- - - - N:ContentInformation
- - - - - N|P:Document-type-specific fields

Which properties apply to the document and which apply to the revision? Title, Navigation Title, Subject, and Description could be either. They could also be moved to Nodes with their own versioning, but that may be overkill. Does rollback to a revision also rollback those fields? Do we need a history of changes to those fields? Should changing the Title create a new revision? Those answers will determine the best structure.

Lenya 1.2's various sitemap.xml files should be built dynamically from the content. That may require caching for good performance.

Subdocuments should not be Nodes of their parent document. There has been much discussion about using a unique identifier for every document. This can be implemented as a minor change to the above. First, discard the "N:Document" node. It would not be necessary because there would be no N:SubdocumentID nodes. Second, add a P:ParentDocumentID.

Now use a flat structure:
- N:Hierarchy (created from the Document Nodes, could include information such as Visibility, substitute for sitetree.xml)
+ N:DocumentUniqueID
- - P:ParentDocumentID - only if a subdocument
- - P:Path
- - Everything under N:Document above

This is really good for many reasons:
1. No need to distinguish between content Node and subdocument Nodes.
2. Easy operation on multiple or all documents, such as building the Search index.
3. Easy moving of subdocuments. Just change the ParentID, rather than moving Nodes.
4. Easy creation of flat views. See all documents by Title, Author, Status, Type. The Status view will show all documents having versions waiting to be published. The Type view can show all Employees, even if they are created as subdocuments of Departments.
5. All information is stored in the Document Nodes, so "Visibility" and "Navigation Title" are available when working with the document.

It also imposes additional concerns:
1. The tree of documents (N:Hierarchy) must be maintained for easy transversal. It should only contain the DocumentUniqueIDs. Creating sitetree.xml should access the document Nodes for the Visibility property. This allows creating menus based on other properties. Eventually someone will add individual document security, and menus will be built to show only the documents allowed to each person (based on their name and/or Groups).

2. What happens to orphans? Subdocuments will not automatically be deleted when the Document Node is deleted. It would be easy to create a view of documents that have ParentDocumentIDs that no longer exist. Or the Delete process could also delete all subdocuments recursively.

<< Notes: Dev ML 3Old: Area >>

Contact Solprovider
Paul Ercolino