Hi Lenya users,
during the meeting in Freiburg, we discussed options for storing
multiple content items in a document. A typical usage scenario is
"related content", usually displayed outside the content column on a web
page.
The following approaches can be used at the moment, including some of
their disadvantages:
Embedded
========
* e.g. using custom elements like <foo:related/>
* require extending the schema
* no clear separation from the actual content
Meta data
=========
* kind-of a misuse of meta data, since it is actual content that is
displayed on the page
* no out-of-the-box support for XML content
* no validation
Separate (child) documents
==========================
* no shared versioning
* shared editing is complicated to achieve
The requirement raises the obvious question if we should support
multiple content items per document out-of-the-box. I see several
implications that would have to be discussed, for instance:
- How would that influence the notion of a resource type? Would it apply
to single content items, or to a whole document containing a set of
content items?
- How would the possible content items of a document be declared? Would
that be part of the resource type? Maybe we'd need two layers:
* document type (set of possible content types, cardinality, …)
* content type (XML schema, XSLT, …)
- Would it make sense to merge this with the meta data storage (e.g.
introduce an abstract concept like JCR nodes+properties, using
properties for meta data)?
- How do other CMSs handle this?
It would be great if you could join the discussion if you're interested
in this feature. TIA!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
