Maybe my work can help with the concepts. This is why I migrated to
UUIDs first, and will worry about JCR in a later release. In my
version:
Each Resource has a type. The basic list is "xml" (Document), "file"
(Asset), and "link". I am about to add architectural elements like
"structure" due to the "Rant" thread to gain the Resource's easy
rollback/undo. Eventually even programming elements could be
Resources.
(OT: Still working on what to do if the "index" node is deleted.
Since the resources are maintained separate from the structures, this
is complex. OTOH, a structure can have multiple root nodes, so the
homepage ("index") could be its own structure, and the second-level
nodes should be top-level nodes in the menu structure. I will try
that.)
Resources have a uuid (unique key), id (used for URLs), type (see
above), defaultlanguage (only for Resources where translations are not
needed), doctype (only for XML). They contain Translations.
Translations have the live and edit revision keys. Most requests
default to the "live" revision, and the Implementation knows which
revision is live. The "edit" revision is the last one saved, so
authoring knows which revision to use. Only the rollback/history
screen will contain multiple revisions. Translations contain
Revisions.
Revisions have unique key (time-based), title, extension (only if
binary data), and whatever XML is necessary for the doctype.
Example XML data:
uuid/resource.xml
uuid/language/translation.xml
uuid/language/revision-uuid.xml
Binary data adds the extension attribute to revision-uuid.xml, and
uuid/language/revision-uuid.extension
The API is:
Content.getFilename(uuid, language, revision)
Content.getMetaFilename(uuid, language, revision)
getMetaFilename always returns the appropriate revision-uuid.xml.
getFilename returns the same unless there is an extension, then it
returns the binary file.
These functions return something suitable for the Resolver. I should
rename them to something more generic. The JCR Implementation might
call them getRevisionData() and getRevisionMeta() because it would not
contain "files".
Implementation Notes:
- A Resource key is called "unid" in my code (remains from my Domino
work). The implementation is a String of any length that can be used
as a directory name. The migration routine uses "0001", "0002", etc.,
but there is not reason a UUID could not be used.
- Revision keys are generated by Long.toString(new
java.util.Date().getTime()). I am adding a CreatedTime attribute so
revision history can sort them and the keys can be anything (same
restrictions as the Resource keys), so they could be UUIDs. It is
easier for humans if the filenames are ordered, but we could always
sort them by the OS's created time.
I hope this helps,
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
