Hi Gerd,
[EMAIL PROTECTED] schrieb:
[…]
On almost any page in the publication(s) we need/use some
'page-related' content like teasers, download-links, links to
external resources (not in the publication) and other information
what is not really a part of the page-(main)content as for example a
link or image inside the article. For this related content we need
the option to use xhtml elements for formatting/structuring, so
text-only is no option. At the moment (in Lenya 1.2.4) we use DIVs
with special IDs within the pagebody of our XHTML-document type. This
requires to 'extract' these data from the main-content on
pagerendering. For editing we've to use a customised TinyMCE-based
edit view with multiple instances of Tiny on the page. Although this
works fine I'm looking for a 'cleaner' way to structure/separate the
related content from the main content.
My idea is to use a custom set of Metadata. Is this possible or even
worst practise?
IMO this would somehow contradict the meaning of meta data - IIUC you
want to managa data here, not data about data. Another disadvantage is
that there is no out-of-the-box validation for meta data values.
As far as I understood custom Metadata in Lenya(2) it
would fit perfectly for this if it's possible/allowed to use
xhtml-formatted content in the <value /> elements.
The meta data are just strings, so you could probably store XML. I've
never tried it, maybe someone else did?
The benefits I
see instead of the use of new resource types is, that it's:
- useable for any (existing) document
This could also be achieved by including a separate document, couldn't it?
> - no need to create many new resourcetypes to add these fields
Maybe a single resource type (with a flexible schema) would be sufficient?
> - independent (from the document content) editable/versionized
I don't quite understand this - the meta data are versioned together
with the document, but if you'd use separate documents for your related
content, you could edit them separately and they would have their own
version history.
I'd probably use an additional resource type (e.g., "relatedContent"),
and store the content in dedicated documents. To make the GUI easier,
you could add an "Edit related content" item to the menubar of "normal"
pages (if there is a 1-to-{0,1} relation between normal pages and
related content).
-- 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]
