I would like to be allowed to use metadata values in the body of topics. I propose the syntax used is (almost) exactly the same used for definition, e.g.:

blah bla blah bla .... My parent Topic is %META:TOPICPARENT{name}% .... blah blah blah ... The lenght of the attached "Goofy" file is %META:FILEATTACHMENT{name="Goofy.jpg" size}%

• the fully specified attributes (filename in the example) operate as filters on the set of metadata values
• When the value is single it's rendered as a single string
• When the value is multiple (multiple columns or multiple rows) then it's rendered as a table

Examples:

• by writing just %META:FILEATTACHMENT% we get the attachment table with all its attributes in single columns.
• by writing %META:ATTACHMENT{name size}% we select only the name and size columns
• by writing %META:ATTACHMENT{name="Goofy.jpg" size}% we select only the attachment with name="Goofy.jpg" and we show its size

All this suggest to make also a general interface to databases to generate tables and use tha same syntax (e.g. %DB:<QUERYNAME>{key="1*"}%) or some kind of SQL syntax.

Probably the best way to handle this is through some kind of MetaDataValuesPlugin and/or DatabaseQueryPlugin.

-- AndreaSterbini - 21 Jun 2001

I think the basic idea is a good one. But since these variables and the actual meta data are in the file, we need to be able to easily distiguish which is which.

Could instead have %META{type="FILEATTACHMENT" name="Goofy.jpg"}%

Could infact use this to render of view/preview/edit templates, rather than adding everything to %TEXT%.

If we do this, I think it should be in core. Plugins could do different formatting, once we pass meta data to them in API.

-- JohnTalintyre - 21 Jun 2001

Well actually if the %META:_END% tag is in there, then distinguishing between them should be no problem, however, I do agree with you that it might make more sense to have a slightly different syntax. I can think of two alternatives:

1. Use additional tags to divide the file into logical sections (should I say meta-meta data), for example:
   %PART:META%
   metadata ....
   %PART:BODY%
   body text ....
   (just a possible extension of the %META:_END% idea that avoids naming conflicts), this could allow for further extensions like separate text bodies i.e., for a main text to be separated from a bulletin-board comment style.
2. Use something like %SHOWMETA:FILEATTACHMENT{...}% or %RENDER:TOPICPARENT%, that is use a different base tag. It should not matter to the user anyway, as the actual meta-text should not be visible and it is just a logical extension of the format. Modifying the format could have problems i.e. what happens if in your example "type" is a meta-data field for FILEATTACHMENT?.

-- EdgarBrown - 27 Jun 2001

Some basic capability now in CVS, please see MetaDataRendering

-- JohnTalintyre - 28 Jun 2001