J. Wolfgang Kaltz wrote:
[...]
- do I understand correctly that the MetaDataRegistry is the place
telling us what kinds of meta-data exist, and within these types, what
individual attributes ?
Yes, exactly. You have the methods
String[] MetaDataRegistry.getElementSetNames()
ElementSet MetaDataRegistry.getElementSet(java.lang.String name)
to access meta data element sets. There are no setters, because
this should be handled by the particular implementation (reading
configuration files, using Avalon etc.).
The document provides access to the meta data:
MetaData Document.getMetaData(String elementSet)
The ElementSet must be registered in the MetaDataRegistry.
The purpose of this architecture is to ensure content integrity, e.g.
if you import content from another Lenya instance.
- What exactly is the relation between ContentNode and Document ?
A ContentNode is a collection of all language versions of a content item.
You can imagine it as a tree:
- publication
- content
- content node: "foo"
- document: en-version of "foo"
- document: de-version of "foo"
- content node: "bar"
- document: en-version of "bar"
- document: de-version of "bar"
- How are assets handled ? Are they ContentNodes ?
An asset would be stored in a Document. The API would allow to
use different actual assets for different language versions, e.g.
a Mercedes-Benz for the German teaser image and a Chrysler for the
US-English one.
Regarding the comment "I'm not sure if a site node should be able to
reference a document, a content node, or maybe both"
-> IMO that depends on how the relation between ContentNode and Document
is defined (see above)
Actually both versions support URL spaces in different ways, assuming
that the site structure corresponds to the URL space.
If content nodes are referenced, it is easier to implement
/foo_de
/foo_en
/foo/bar_de
/foo/bar_en
If documents are referenced, it is easier to implement
/de/foo
/en/foo
/de/foo/bar
/en/foo/bar
Maybe it would be helpful to instantiate this model on a scenario ?
For example, what would it look like if
- we have a root document named "My Life"
- this document has some XHTML text, and an asset "mymotorcycle.jpg"
- this document has a child document "My Hobbies"
- the child document has some XHTML text, and two assets: "lasttrip.pdf"
and "mymotorcycle.jpg" (i.e. references the same asset as the document
"My Life")
It would look like this:
* Publication
* Area
* Content
* ContentNode "My Life" (DocumentType XHTML)
* Document en incl. reference to "MotoCycle"
* ContentNode "My Hobbies" (DocumentType XHTML)
* Document en incl. references to "Last Trip" and "MotoCycle"
* ContentNode "Last Trip" (DocumentType PDF)
* Document en
* ContentNode "MotoCycle" (DocumentType Image)
* Document en
* Site "Website"
* SiteNode "mylife" -> ContentNode "My Life"
* SiteNode "hobbies" -> ContentNode "Hobbies"
You could use another site structure for assets:
* Site "Assets"
* SiteNode "images"
* SiteNode "motocycle" -> ContentNode "MotoCycle"
* SiteNode "documents"
* SiteNode "lasttrip" -> ContentNode "Last Trip"
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
