| |
| META TOPICPARENT | name="WebHome" |
TWiki Meta Data |
|
< < | Meta Data Definition |
> > | What is Meta Data in TWiki? |
| | |
|
> > | What, indeed!
Defining Meta Data Variables |
| | See Meta Data Rendering for variables used to display meta data.
Current version: 1.0 |
|
< < | Example of format |
> > | Syntax |
| | |
|
> > |
- Format is as for [[TWikiDocumentation#TWiki_Variables, except all fields have a key.
- %META:<type>{key1="value1" [key2="value2" [...]]}%
- Order of fields within the meta variables is not defined, except that if there is a field with key
name, this appears first for easier searching (note the order of the variables themselves is defined)
- Each meta variable is on one line
- '\n' is represented in values by
%_N_ and '"' by %_Q_%
Example of Format |
| |
%<nop>META:TOPICINFO{version="1.6" date="976762663" author="PeterThoeny" format="1.0"}%
text of the topic |
|
< < | %META:TOPICMOVED{from="Codev.OldName" to="CoDev.NewName" by="JohnTalintyre" date="976762680"}% |
> > | %META:TOPICMOVED{from="Codev.OldName" to="CoDev.NewName" |
|
> > | by="JohnTalintyre" date="976762680"}% |
| | %META:TOPICPARENT{name="NavigationByTopicContext"}%
%META:FILEATTACHMENT{name="Sample.txt" version="1.3" ... }%
%META:FILEATTACHMENT{name="Smile.gif" version="1.1" ... }%
%META:FORM{name="WebFormTemplate"}%
%META:FIELD{name="OperatingSystem" value="OsWin"}%
%META:FIELD{name="TopicClassification" value="PublicFAQ"}%
|
|
> > | |
| | |
|
< < | General notes |
> > | Specifications |
| | |
|
< < |
- Format is as for [[TWikiDocumentation#TWiki_Variables, except all fields have a key.
- %META:<type>{key1="value1" [key2="value2" [...]]}%
- Order of fields within the meta variables is not defined, except that if there is a field with key
name, this appears first for easier searching (note the order of the variables themselves is defined)
- Each meta variable is on one line
- '\n' is represented in values by
%_N_ and '"' by %_Q_%
Logical order
There no absolute need for meta data to be in a specific order, however, it does for the following reasons:
- Keep (form) fields in the order they are defined
- Allow diff command to give output in a logically sensible order
These could be done in other ways, but this adds complexity
- Order fields - definition could be read on each rendering (expensive)
- Diff - render data before doing diff, has something to offer, but not likely to be available for next TWiki release
So the order is:
- TOPICINFO
- text of topic
- TOPICMOVED - optional
- TOPICPARENT - optional
- FILEATTACHMENT - 0 or more entries
- FORM - optional
- FIELD - 0 or more entries (FORM required)
Specification |
| | TOPICINFO
| Key | Comment |
| version | Same as RCS version |
| date | integer, unx time, seconds since start 1970 |
| author | last to change topic, is the REMOTE_USER |
| format | Format of this topic, will be used for automatic format conversion |
TOPICMOVED
This is optional, exists if topic has ever been moved. If a topic is moved more than once, only the most recent TOPICMOVED meta variable exists in the topic, older ones are to be found in the rcs history.
%META:TOPICMOVED{from="Codev.OldName" to="CoDev.NewName" by="talintj" date="976762680"}%
| Key | Comment |
| from | Full name i.e. web.topic |
| to | Full name i.e. web.topic |
| by | Who did it, is the REMOTE_USER, not WikiName |
| date | integer, unx time, seconds since start 1970 |
Notes:
- at present version number is not supported directly, it can be inferred from the RCS history.
- there is only one META:TOPICMOVED in a topic, older move information can be found in the RCS history.
TOPICPARENT
| Key | Comment |
| name | The topic from which this was created, WebHome if done from Go, othewise topic where ? or form used. Normally just topic, but is full web.topic format if parent is in a different Web. Renaming a Web will then only break a few of these references or they can be scanned and fixed. |
FILEATTACHMENT
| Key | Comment |
| name | Name of file, no path. Must be unique within topic |
| version | Same as RCS revision |
| path | Full path file was loaded from |
| size | In bytes |
| date | integer, unx time, seconds since start 1970 |
| user | the REMOTE_USER, not WikiName |
| comment | As supplied when file uploaded |
| attr | h if hidden, optional |
Extra field that are added if an attachment is moved:
| movedfrom | full topic name - web.topic |
| movedby | the REMOTE_USER, not WikiName |
| movedto | full topic name - web.topic |
| moveddate | integer, unx time, seconds since start 1970 |
FORM
| Key | Comment |
| name | A topic name - the topic is a Form Template. Can optionally include the web name i.e. web.topic, but doesn't normally |
FIELD
Should only be present if there is a FORM entry. Note that this data is used when viewing a topic, the form template definition is not read.
| Key | Name |
| name | Ties to entry in Form Template, is title with all bar alphanumerics and . removed |
| title | Full text from Form Template |
| value | Value user has supplied via form |
|
|
< < | Viewing meta data |
> > | Recommended Sequence |
| | |
|
> > | There no absolute need for meta data variables to be in a specific order, however, it does for the following reasons:
- Keep (form) fields in the order they are defined
- Allow diff command to give output in a logically sensible order
These could be done in other ways, but this adds complexity
- Order fields - definition could be read on each rendering (expensive)
- Diff - render data before doing diff, has something to offer, but not likely to be available for next TWiki release
So the order is:
- TOPICINFO
- text of topic
- TOPICMOVED - optional
- TOPICPARENT - optional
- FILEATTACHMENT - 0 or more entries
- FORM - optional
- FIELD - 0 or more entries (FORM required)
Viewing Meta Data in Page Source |
| | When viewing a topic the Raw Text link can be clicked to show the text of a topic (ie: as seen when editing). This is done by adding raw=on to URL. raw=debug shows the meta data as well as the topic data, ex: debug view for this topic |
|
< < | Future Plugins support |
> > | Future Support for Plugins |
| | There is currently no support for meta data for Plugins. However, the format is readily extendable and the Meta.pm code that supports the format needs only minor alteration.
|
|
< < | Meta Data Rendering |
> > | Rendering Meta Data |
| | |
|
< < | Various meta data can be stored in topics. The data is rendered using the %META% variable. This is mostly used in the view, preview and edit scripts. |
> > | Various types of meta data can be stored in topics. The data is rendered using the %META% variable. This is mostly used in the view, preview and edit scripts. |
| | Current support is fairly basic:
| Variable usage: | Comment: |
| %META{"form"}% | Show form data, see Form Templates |
| %META{"attachments"}% | Show attachments, exclude hidden |
| options for attachments: |
| all="on" | Show ALL attachments (including hidden) |
| %META{"moved"}% | Details of any topic moves |
| %META{"parent [options]"}% | Show topic parent |
| options for parent: |
| dontrecurse="on" | By default recurses up tree, at some cost |
| prefix="..." | Prefix for parents, only if there are parents; default "" |
| suffix="..." | Suffix, only appears if there are parents; default "" |
| seperator="..." | Separator between parents, default is " > " |
|
|
< < |
- Possible future additions:
- Rendering of form data to alternate formats, ex: bullet lists
- Specify a template to be used for rendering
|
> > |
- Future Development: There are numerous development directions and specific features to consider. A couple of obvious possibilities:
- Rendering to formats other than tables: bullet lists, formatted body text;
- Specifying templates to be used for rendering.
|
| | -- JohnTalintyre - 29 Aug 2001
|