Feature Proposal: Fix and document field values to enhance templates
Motivation
It is quite easy to write a skin template and put a macro in it or a form field value. For instance NatSkin uses
TopicTitle
to split out the title from the topic text.
This proposal is about defining a number of these values so that the become "reserved keywords" and templates (f.i. BaseSkin) can prepare for them.
I would like to propose these data fields:
Description and Documentation
This is mainly an API proposal, to fix and document desired functionality. It is not necessary to code anything right now.
Examples
Impact
Implementation
--
Contributors: ArthurClemens - 17 Oct 2012
Discussion
Summary
(instead of
TopicDescription
) is used in
WikiWorkbenchContrib,
ClassificationPlugin,
BlogPlugin and
SolrPlugin, and whatever contrib builds on WikiWorkbench.
--
MichaelDaum - 17 Oct 2012
TopicDescription is definitely more revealing than Summary. (I too have wikiapp things that use Summary, but its better to use a consistent and more verbose use of the namespace.
for this reason, I also suggest that it be called TopicIntroduction
--
SvenDowideit - 17 Oct 2012
Arthur, could you please explain a bit further in how far your proposal is
template specific. I'd expect such a convention would affect more than just the (skin) templates.
The term "dynamic values" doesn't ring a bell either.
--
MichaelDaum - 19 Oct 2012
Of course, data comes first: you need to have a data form with a TopicTitle field. That goes beyond templates only. But templates need to cater for possible data field values. I would like to make sure that - regardless the skin - some data values will be displayed as intended.
It helps if the topic title is always called TopicTitle, so it can be implemented in the base skins.
If you have other names, you could override them in sub skins. But at least it will be clear that it is an override.
For instance:
Orginal implementation (roughly):
<meta name='description' content='%TMPL:P{"head:meta:description"}%' />
...
%TMPL:DEF{"head:meta:description"}%%FORMFIELD{"TopicDescription"}%%TMPL:END%
Sub-skin implementation:
%{
Overriding TopicDescription with Summary
}%
%TMPL:DEF{"head:meta:description"}%%FORMFIELD{"Summary"}%%TMPL:END%
--
ArthurClemens - 19 Oct 2012
Oic. Well, that shouldn't depend on a data form being present imho.
NatSkin checks for a METADESCRIPTION preference variable before trying to access any DataForm. Same for keywords and author.
Along these lines:
%TMP:DEF{"metadescription::formfield"}%Summary%TMPL:END%
%TMP:DEF{"metakeywords::formfield"}%Tag%TMPL:END%
%TMPL:DEF{"metaauthor"}%%SPACEOUT{"%USERINFO{"%QUERY{"'%WEB%.%TOPIC%'/versions[-1].info.author"}%" format="$wikiname"}%"}%%TMPL:END%
%TMPL:DEF{"metadescription"}%%IF{"defined 'METADESCRIPTION'"
then="<meta name='description' content='$percntENCODE{\"$percntMETADESCRIPTION$percnt\" type=\"html\"}$percnt' />"
else="$percntFORMFIELD{\"%TMPLP{"metadescription::formfield"}%\" format=\"<meta name='description' content='$dollarpercntENCODE{\\"$value\\" type=\\"html\\"}$dollarpercnt' />\"}$percnt"
}%%TMPL:END%
%TMPL:DEF{"metakeywords"}%%IF{"defined 'METAKEYWORDS'"
then="<meta name='keywords' content='$percntENCODE{\"$percntMETAKEYWORDS$percnt\" type=\"html\"}$percnt' />"
else="$percntFORMFIELD{\"%TMPL:P{"metakeywords::formfield"}%\" format=\"<meta name='keywords' content='$dollarpercntENCODE{\\"$value\\" type=\\"html\\"}$dollarpercnt' />\"}$percnt"
}%%TMPL:END%
%TMPL:DEF{"metaauthor"}%%IF{
"defined 'METAAUTHOR'"
then="<meta name='author' content='$percntENCODE{\"$percntMETAAUTHOR$percnt\" type=\"html\"}$percnt' />"
else="<meta name='author' content='$percntTMPL:P{\"metaauthor\"}$percnt' />"
}%%TMPL:END%
This will open a way to feed seo data via a wiki app in WebPreferences as well.
--
MichaelDaum - 19 Oct 2012
Developer is no longer contributing. Changed status to 'ParkedProposal'
--
Main.CrawfordCurrie - 11 Jan 2016 - 18:00