Andreas Hartmann wrote:
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!
i used to do something like that in a project that unfortunately never
went live...
my approach was to create a doctype "aggregation" that was basically an
xquery that could take querystring parameters and transform them into an
xml database query. maybe we could do something like that? the actual
content is stored in content documents, and the page people view is an
aggregation document that gets parameters pointing to content documents
or maybe has hardcoded pointers in it.
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]