Hi Andreas,
I tried with the custom metadata and basically it would be perfect for our
needs if the (xml-)formatting would work... hopefully I only missed something
in what I did:
my test-value is "just <b>bold</b> text" (without the quotes).
I configured the input module as described on the website
(http://lenya.apache.org/docs/2_0_x/reference/metadata.html) and passed the
value as parameter to the transformation.
The value I get is "just <b>bold</b> text", exactly as it's stored
in the file "en.meta".
When I manually change the value in the file to my original test-value (see
above) only "just text" is returned (the <b/> element is removed).
Best Regards,
Gerd
> 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]
>
>
--- original Nachricht Ende ----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
