Feature Proposal: Topic display title
Create the possibility for a display title (the way a topic is shown as link) for every topic.
Motivation
Display (topic) names are useful for several reasons. They:
- Are less geeky than WikiWords and may broaden the user base
- Show a more relevant name than is possible within WikiWord constraints
- Give meaningful names to autogenerated topic names
- Create links that can be picked up by search engines (normally almost no twiki pages show up when looking up my name on Google, while a link "Arthur Clemens" will be indexed - of course my name is just a silly example)
- Make better navigation menus because long link names are split by the space delimiter
- Remove almost all need for underscore_wiki_words (underscore names achieve the same at almost no performance loss, but introduce new linking syntax)
There are several ways to create a display name:
- Manually entered in a 'name' form field, to show: "Topic display name" with the current topic
- Set by a variable
NAME
in the topic text
- Based (automatically) on a person's name, to show: "Arthur Clemens" with my signature
- Based on the first header in the topic (AutomaticLinkLabelBasedOnHeading), to show "Feature Proposal: Topic display name" with this topic
- Expensive with looking up for each topic, but may be set in a variable when saving the topic
- May be useful on some sites
- The other way around is also likely: the first header is generated from the topic's name
Why not always use display names?
- WikiWord topic names make easy links and are generally easier to remember than a less contrained display name
- A topic name does not change that often, and when it does relinking is possible
- A topic name can be written as a logical part of a sentence that may be broken when a display name is used that changes
- A topic name is a (human readable) page id; sometimes it is important to refer with certainty to a specific page
If we want to keep all that, we can say:
- Do not change the appearance of all Legacy.WikiWord topic names automatically into display names, but make this optional for each link
- So do not change the working of the notation
SomeTopic
or [[SomeTopic]]
- Create instead a new syntax to show a topic's name. For instance:
-
[[^SomeTopic]]
(the ^ refers to alias - and is not a legitimate url character so does not clash)
-
^SomeTopic
-
SomeTopic.name
(OO)
-
[[SomeTopic][]]
(leave link label empty, so default to the topic display name)
More rules:
- The name variable may be set:
- in a form field
- in a topic variable (Set NAME = )
- on a More page
- in a meta field like PARENT
- by a plugin
- The name may be derived from the user's name values when creating a user page
- A display name may be used with search results, so an equivalent
$name
parameter should be build for formatted searches
- A name variable may be set using a url param, for instance when creating a topic by a form
--
ArthurClemens - 16 Feb 2006
Impact
- changes the way WikiWords are rendered
-
[[WikiWord]]
... display its title if available, fallback to WikiWord
-
[[Web.WikiWord]]
... display its title if available, fall back to Web.WikiWord
-
[[WikiWord][explicit link text]]
... display "explicit link text"
- when sorting lists of topics and render their WikiWord using the topic title sorting might look wrong when the topic title diverges too much from the topic name
- any macro that may sort by topic also needs a way to sort by title, i.e.
%SEARCH
and %TOPICLIST
Implementation
- support storing a topic title in either in
META:PREFERENCE
called TOPICTITLE or in a TopicTitle formfield of a DataForm
- display topic titles when rendering WikiWords
- move handling of topic titles during
save
out of NatEditPlugin into Foswiki::UI::save
- add a perl api
Foswiki::Func::getTopicTitle
for plugins to fetch the topic title
- implement a
%TOPICTITLE
macro to be used in wiki apps
- add a "change title" in the rename-topic dialog, including a "derive topic name from topic title" checkbox (see NatSkin)
- review JQueryAjaxHelper to display topic titles when selecting topics (or users)
- review plugins that implement a local
getTopicTitle
perl api to use the core api if available
--
MichaelDaum - 16 May 2014
Discussion
This is exaclty what I want! The most wanted feature is a good looking page title in the browser window!!!
In my opinion, it is not necessary to use the costly TOC algorithm but instead use always the '---+' header one tag for page titles, as even if not using a header but some sections, in most cases nobody want section A to be a header for a document, that contains also section B and C (in the same level). So, if no TOC is requested, there should be no need for an extra rendering-just-for-toc-generation step. On most pages this header tag will used together with '!!', so '---+!!' is definitelly a header, no need to search for more.
So, what minimal effort has to be done?
- change the line containing
%TOPIC%
to %PAGETITLE%
in the templates
(for transition time a construct accepting both variables like %IF{'defined PAGETITLE' then='%PAGETITLE%' else='%TOPIC%'}%
could be there)
- automatically find the value of
PAGETITLE
(or NAME
if you want) if not set manually, which could be a simple regexp that matched the first occurrence of '---+'
- enhance URL syntax to support '^' notations
- enhance =
Number of topics: 0
= and maybe other makros
Some guidelines for the documentation when to use short and when long links would be a good idea, too.
So, anybody there, who is not convinced yet? Are you happy with a start page called 'Legacy.WebHome' instead of 'Welcome to the Collaboration Plattform of XYZ'? Please try
Google:Legacy.WebHome - I got more then
12.000.000
results and more then
6.000.000
for
Google:'Legacy.WebHome Main'. Looks funny, and I'm sure, your company XYZ is under the top ten.
PS. As mine label ist not the famous XYZ, I'm still looking for a quick patch against Dakar to reach the second step as fast as possible. Atm I set
PAGETITLE
manually.
--
TobiasRoeser - 22 Feb 2006
There is no need for the
IF
. Add the
Topic Display Name
var to the core and default it to
%!TOPIC%
--
RafaelAlvarez - 23 Feb 2006
What is the preferred way to set a variable (
PAGETITLE
) programmatic, that can be seen in a template file? Is it neccessary to write a plugin? And when, what is the best call (to TWiki::Func) to set such a variable.
--
TobiasRoeser - 30 Mar 2006
I think that we need a either a new plugin handler (to make it a plugin) or to change the way the
WikiWord links are rendered.
--
RafaelAlvarez - 30 Mar 2006
Sorry, but the latter part is not clear for me. What I want to know is how to set a (internal) variable
PAGETITLE (our page title var) calculated while processing the page so that the value of
PAGETITLE is available when the page gets rendered using a template. So the value of this variable
PAGETITLE should expanded in the template like any other variable e.g.
TOPIC
. Why we have to change the way of rendering
WikiWords?
--
TobiasRoeser - 31 Mar 2006
Ahh, you mean that. Just set a preference in the page. Ex:
- Set PAGETITLE = Topic Display Name
will be rendered as "Topic Display Name" wherever
%PAGETITLE%
is used.
I was thinking more along the lines that when TopicDisplayName is referenced,
Topic Display Name
is rendered. For that you need to modify the way wikiwords are rendered.
--
RafaelAlvarez - 31 Mar 2006
A thanks for clarification. But the
Set PAGETITLE
option is what I use already (see post from 22 Feb). I want to set this programmatic instead of manually. So, while TWiki parses the page, it recognizes a
---+!!
and if it not finds a
Set PAGETITLE
then is assumes the heading of the page as
PAGETITLE
. This way, you can always override the page title, but if not, its default is the page heading. But to render this title, we have to set a preferences variable which is visible in the view template anyway. But until now, I could not find any TWiki function, that can set a new preferences variable.
For topic references, I like Arthurs suggestion. Don't change the default behaviour and provide a new link style e.g.
[[^SomeName]]
which expand to the full page title because of the presence of the
'^'
sign.
--
TobiasRoeser - 31 Mar 2006
The first step would be adding a handful of
Preference
functions which would operate on the
settings
part of a topic; i.e.
SetPreference
,
GetPreference
,
ClearPreference
. These could then be used to set the pagetitle in some automatic, as-yet-unspecified way.
--
MeredithLesly - 31 Mar 2006
A thanks, then I was right, that there is not such function at the moment.
Ok, first I will get my
SearchByCreateDate patch finished. Afterwards, I will try to prepare some patches for discussion, but this can take some time, as I have to get prepared for my final examinations.
--
TobiasRoeser - 31 Mar 2006
To support discussion I've created a wireframe that shows the separate phases of topic display names: creation, editing and linking.
--
ArthurClemens - 17 Apr 2006
hm, i think you've left off the most useful notation:
[[Corporate identity]]
.
of course, it would be even nicer if you could simply type
Corporate identify
, and twiki would automagically resolve the link, but
phrase-based linking is a completely different feature discussion...
--
WillNorris - 17 Apr 2006
Exactly, it is complementary. Topic display name is about getting a name (phrase)
when referring to the topic id or Legacy.WikiWord.
- I want to get the display name in another topic. Of course I could write
[[Will Norris]]
every time I need a link to WillNorris, but that wouldn't be convenient. I want to write ^Main.WillNorris
(or equivalent notation) and get Will Norris displayed.
- There needs to be a way to get the topics display name when doing a search. For instance with
$name
.
--
ArthurClemens - 17 Apr 2006
A picture is worth a thousand words.
--
RafaelAlvarez - 17 Apr 2006
To summarize the current state, as this discussion stagnates:
This functionality is completely accepted, at least the issue, that it should somehow possible to display nicer page names and to refer to them from other sites. As Meredith stated in her post from 31 Mar 2006, the big blocker are some missing "
Preferences
functions which would operate on the
Settings
part of a page". So all we need is a code/design proposal. Unfortunately, I'm not as familar with this part of TWiki's heart as I would be. Can somebody assist/guide/mentor me, where to start. Hints on some docsm where the current preferences system is described, would be useful.
--
TobiasRoeser - 29 Apr 2006
What is the best way to start this? I think first we need to agree where/how the topic name is stored (META?).
--
ArthurClemens - 20 May 2006
There are two ways of creating topic preferences. One is indeed done via
META
and adding the functions to TWiki::Func shouldn't be that hard. (I didn't know how when I wrote my 31 Mar comment.)
--
MeredithLesly - 21 May 2006
I really like the idea to have a display name instead of the wiki name when linking to a topic. Part of that is already in the BlogPlugin in a different vesture where
%CITEBLOG{"Blog.BlogEntry911"}%
will expand to
"<Headline>" by <Author> (<Date>)
of that posting, where
<Headline>
,
<Author>
and
<Date>
are formfields.
It would be greate to make this more userfriendly, i.e. not using a twiki tag.
Making a "display name" a standard meta data seems to be the right thing to do. Even nicer if I can put in a TML expression that gets
expanded as I'd like to have
"%FORMFIELD{"Headline"}%" by %FORMFIELD{"Author"}% (%FORMFIELD{"Date"}%)
in it for example.
--
MichaelDaum - 28 Jun 2006
Thought there already is a
FORMFIELD
'variable' (see
TWikiVariables#FORMFIELD_fieldname_renders_a_fi).
- Yes, but this would require topics to have a form. And if they have a form already, the form would need this
topic name
field. And the syntax to request the value is not easy to use. -- ArthurClemens - 28 Jun 2006
--
FranzJosefGigler - 28 Jun 2006
Topic display name is also what Confluence does:
Rename page is no longer a separate function. Just edit the page and change the page title, and Confluence will rename all the links to the page for you. Confluence - Where did everything go? - Rename (plus screenshot).
--
ArthurClemens - 18 Jul 2006
Oh, I like the interface changes to confluence discussed on that page. There are some questions and remarks:
- What is their url pattern? There seem to be three different url styles that link to the same space: (1) tiny urls forwarding to (2) space-pagename urls and (3) viewpage.action+pageId urls.
- (1) and (3) are pretty ugly and aren't thought to be memorizable by humans, I guess
- Having different urls linking to the same page is bad for google.
- How do they resolve page name clashes for type (1) and (3) urls?
- Every page in confluence has a pageId, so pages can be referred to independent of their name.
- Editing the page name as a separate input field as well as its parent on the same screen makes perfect sense. Editing the parent this way should be possible in TWiki too. Note that there is a magnifier icon probably opening a separate name selection box thereby decoupling it from generating the edit dialog (performance).
- Last not least: they have a usability process
- Of course. They design what to build, and how to build it. Write and design specs. Code the backend and the interface. I have tried this approach when I was new to TWiki, but here things work differently. There is no weight behind proposals, except for personal interests. Which is explainable, but a shame nonetheless. -- ArthurClemens - 19 Jul 2006
--
MichaelDaum - 19 Jul 2006
I want you all to remember one thing.
If you would like a major part of your links to not show the name of the topic but some data stored in the topic that this link points to then it means that for every such link - some code has to open the target file and read the data.
We have such a similar feature today called LINKTOOLTIPINFO
Those of you that have tried it - will know that TWiki is running far far slower with this activated. And you can from pure logic guess that opening many files and read a string of each file many links point to in a topic will slow down TWiki.
So make sure this feature - if implemented is made so when you do not use it - it adds no extra load. We need to speed up TWiki. Not slow it further down.
--
KennethLavrsen - 23 Jul 2006
Probably a good idea to think of a cache mechanism for this, i.e. along the lines of what
TagMePlugin is doing.
Another approach could be to do this in AJAX or similar, allowing for a fast first time roundtrip.
--
SteffenPoulsen - 11 Oct 2006
The name variable should be stored in a
META
setting because it inherently belongs to the topic itself (not so much meta data as
TagMePlugin).
And because it is a reserved word, we cannot just use
META:PREFERENCE
(or it could be deleted or changed name in the settings interface). Logical seems to introduce a new
META:TOPICTITLE
field.
Caching can be done as TagMePlugin does with the difference that to feed the cache the topics'
META:TOPICTITLE
value is read.
--
ArthurClemens - 11 Dec 2006
so long as i can set a web / twiki wide variable to that defined the title to be %SPACEDOUT{%TOPIC%}% , and thus never have to see / set / define a redundant META to be that??
--
SvenDowideit - 11 Dec 2006
Is your point using a topic variable, or using
SPACEDOUT
?
--
ArthurClemens - 11 Dec 2006
my point is that I set a web wide variable to give me a html title - often like
* Set TOPICTITLE=%SPACEDOUT{%TOPIC%}% - COMPANY WIKI
--
SvenDowideit - 12 Dec 2006
OK, but the issue here is to display this name in another topic. And to do this without too much performance loss.
--
ArthurClemens - 12 Dec 2006
After coming back one year later I see that there still is no consensus. Pitty, i.e. as Arthur made a very good proposal. I like having a
META:TOPICTITLE
variable including the related interface changes to
edit
. We need this. Can someone please sum up the counter-arguments, please?
--
MichaelDaum - 16 Mar 2007
I like Arthur's proposal, it is intuitive.
Things to consider:
- With Legacy.I18N, are some characters removed/expanded when building the linkage name (aka topic name) from the display name?
- Allow user to change topic name when creating new topic?
- How does a rename of topic work? Chance the display name and topic name?
--
PeterThoeny - 16 Mar 2007
The major warning I keep on repeating is the performance issue.
Each time you view a topic a Legacy.WikiWord link shown with this feature, TWiki will have to read the meta from the topic files to be able to show them. It cannot be done without a major performance hit unless we radically introduce it in connection with an indexed cache.
And it is about time people think beyond a minor release and address this greater problem. Besides display names, access rights, patents-child relations, the topic summaries and the topic names themselves should be in an index so searching for them can happen much faster.
--
KennethLavrsen - 18 Mar 2007
Kenneth makes a good point - something like
TWikiCache is increasingly important for features like this.
This should be
I18N-transparent as long as it's done properly, only valid topic alphanumeric characters, whether
I18N or not, should be allowed. Performance of the feature without
I18N is a much bigger issue.
Would be great to get hold of the
TWikiCache code, if only for my home TWiki which is a bit slow!
--
RichardDonkin - 18 Mar 2007
I do not see any progress on the discussion topic. The spec is defined but technical solution that will work is missing. A topic needs a driver who is committed to implement it.
KennethLavrsen's summary of the proposal.
- Spec is agreed
- Implementation has caused at least Kenneth and also Richard to raise concern about the performance if this gets implemented under the current storage model. This means that this is probably a proposal that needs to get re-addressed for TWiki 5. In a DB storage model this proposal could be implemented very easily without any significant performance hit by having the right indexed tables in the DB with topic display names.
- Proposal is put in parked state ready to get picked up during TWiki 5 development.
--
KennethLavrsen - 25 Apr 2007
Mmm, by thinking about it, I have another technical solution. Just define a perfect functional mapping between TopicDisplayName and TopicFileName. For instance we could use the Web URL quoting of URLs:
- TopicDisplayName = Kenneth Lavrsen's summary of the proposal
- TopicFileName = Kenneth%20Lavrsen%27s%20summary%20of%20the%20proposal
If you look at it, this is what the
SpacedTopicPlugin implements (but one way)
- we also could have a rendering strategy for the URL context like the one used in blog e.g. Kenneth-Lavrsen-s-summary-of-the-proposal
--
ColasNahaboo - 31 Jan 2008
This features has been implemented. See
UserExperienceProjectPageTitle for a further explanation and discussion.
--
MichaelDaum - 09 Nov 2008 - 14:25
Concerns has been raised for performance. It would be useful to measure performance costs.
--
ArthurClemens - 09 Nov 2008 - 16:27
You should never have no concerns about performance
--
MichaelDaum - 10 Nov 2008 - 07:40
Because this is done by DBCachePlugin / DBCacheContrib?
--
ArthurClemens - 10 Nov 2008 - 09:52
That's the fastest we can do that trick right now. This duo is going to be replaced the long run anyway using a real DB backend.
So it is seems to be the right way to go for now.
--
MichaelDaum - 10 Nov 2008 - 12:59
(from
http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2013-10-17,Thu)
TWiki finally implemented
TopicTitle. See
http://twiki.org/cgi-bin/view/Codev/TopicDisplayName,
http://twiki.org/cgi-bin/view/Codev/ShowTopicTitleInLinks and
http://twiki.org/cgi-bin/view/TWiki/VarTOPICTITLE
Their specs are: store the
TopicTitle in a Title formfield if present; fall back to storing it as a TITLE preference variable
DBCachePlugin does the same but uses a
TopicTitle formfield or a TOPICTITLE preference variable
which is better imho as a Title formfield conflicts with lots of
DataForms using Title for something completely different rather than the display name of a topic. E.g. when describing a person Title is something like Mr, Mrs, Dr, Prof or the like.
I haven't looked at the code they added to TWiki-Core to implement it as this is yet to be released as TWiki-6.0.
I wonder though whether they deal with topics that already have a TOPICTITLE preference setting but receive a
DataForm later on having a
TopicTitle formfield.
DBCachePlugin covers these cases by migrating the store location in both directions: (1) adding a form (2) removing a form .
Foswiki-core should add the notion of a
TopicTitle as well moving the feature from
DBCachePlugin into the core.
With
NatEditPlugin being part of the core we are all set in this respect.
Hower there's another important point: renaming a topic
there are a few overlapping use cases here
- create a topic using a TopicTitle only and deriving a TopicName from it (wikification)
- change the TopicTitle of an existing topic
- change the TopicName
- change both TopicTitle and TopicName
- selections and autocompletion for topics
jquery.wikiword helps with (1) and is the default in
NatSkin. so you don't have to think about proper
WikiWords anymore.
With regards to (2) when people change the
TopicTitle a lot over time while the
TopicName stays as it is (stable urls) the danger is that both deviate from each other too much
In this case (4) the UI needs a way to rename the topic matching the
TopicTitle changes as close as possible, again using jquery.wikiword.
This is covered in
NatSkin as well: two input fields - one for the
TopicTitle, one for the
TopicName - and a checkbox "derive from
TopicTitle" which automates the generation of a
TopicName matching the
TopicTitle as close as possible according to the definition of a
WikiWord.
About (5): what users see is the
TopicTitle. Wikiapps however operate on
TopicNames.
So autocomplete and select+values interfaces used to chose a topic need to display the
TopicTitle while selecting the
TopicName as the actual value.
This needs changes to any "pick from list" interface to handle topic parents or the like.
The
TopicTitle proposal logically leads to
WebTitles: the display text when linking to
SomeWeb
Both
TopicTitles and
WebTitles play an important role in breadcrumbs.
Having worked with
TopicTitles in various wiki apps yet another use case came up: the
TopicTitle being agregated by two or more other formfields of a
DataForm.
In some wiki apps it makes more sense to automate the
TopicTitle using two or more formfields
I hope to cover this use case better than before with the next release of
MoreFormfieldsContrib which will come with an autofill formfield type. this one will be auto-filled by concatenating formfields of the same
DataForm being saved.
This works out fine in the current implementation but hasn't been fool-proven in real-world projects yet.
So a
TopicTitle formfield of type autofill will then be able to generate proper
TopicTitles - and thus link texts - based on more complex scenarios.
Example of an autofill
TopicTitle
| TopicTitle | autofill | 80 | source="Title, FirstName, LastName" | | |
| Title | select | 1 | , Mr., Ms., Mrs., Dr., Prof. | | |
| FirstName | text | 30 | | | |
| MiddleName | text | 30 | | | |
| LastName | text | 30 | | | |
--
MichaelDaum - 17 Oct 2013
Some operations, like renaming a topic based on its title, requires
AddFoswikiFuncWikifyWebTopicName
--
MichaelDaum - 02 Apr 2014
I would like to see a specific
TopicTitlePlugin that would add support for a new metadata value META:TOPICTITLE, and the related
ability to access and set that value with appropriate security checks.
I think this would improve upon the
NatEditPlugin +
DBCachePlugin combination by making it easier to include edit fields for the title in
arbitrary topics and templates, eliminate the requirement for
NatEditPlugin to get a title field during edit,
and create a consistent storage field for the title instead of the
DBCachePlugin supported TOPICTITLE preference
or TopicTitle form field. (Isn't
DBCachePlugin an odd place to implement this feature anyway?)
I have implemented a prototype of this concept using
MetaDataPlugin, a few parameterized macros and pattern skin customizations.
Features of this implementation:
- Topic title field is available during edit.
- %TOPICTITLE{"<topic>"}%, generates the title of the topic, or the topic name if there is no title. If "<topic>" not provided will default to the current topic.
- %LINK{"<topic>"}%, generates a link to the specified topic, displaying the topic's title or topic name if there is no title.
- The topic title will appear in breadcrumbs and in the window title for topics it is set on.
- Clicking on the link to a new topic will fill in the topic title field with the text of the link. For example a link to [[CurrentTasks][List of current tasks]] will default the topic title field to "List of current tasks".
Problems:
- I'm only providing pattern skin customization.
- Use of double quotes in the title will break the title.
- Titles can recursively refer to themselves with %TOPICTITLE%, enabling an easy DOS attack.
- Formatting in titles can get out of control, and should probably be limited. Example <marquee>moving title!</marquee>.
Setup:
- Install and enable MetaDataPlugin.
- Create Main.TopicTitleForm, with the content:
---+ Topic Title Form
| *Name* | *Type* | *Size* | *Values* | *Tooltip message* | *Attributes* |
| Name | text | 40 | | | |
- Set site preferences to define the needed macros:
* Set SKIN = topictitle,pattern
* Set WEBMETADATA = Main.TopicTitleForm
* Configure MetaDataPlugin to accept TopicTitleForm as valid metadata.
* Set NEWLINKFORMAT = <a class="foswikiNewLink" href="%SCRIPTURLPATH{"edit"}%/$web/$topic?topicparent=%ENCODE{"%WEB%.%TOPIC%"}%&topictitle=$text&t=%GMTIME{"$epoch"}%" rel="nofollow" title="%MAKETEXT{"Create this topic"}%">$text</a>
* Text of link to new topic is used as the default topic title.
---++ Macros for topic title support
* Set METATOPICTITLESET = %RENDERMETADATA{ "TOPICTITLE" topic="%DEFAULT{default="%TOPIC%"}%" web="%WEB%" name="id1" header="" footer="" format="$Name" fieldformat="true"}%
* Value is 'true', if the topic has the title metadata, even if it is blank. Optional parameter for the topic name to get title from, defaults to current topic.
* Set METATOPICTITLE = %RENDERMETADATA{ "TOPICTITLE" topic="%DEFAULT{default="%TOPIC%"}%" web="%WEB%" name="id1" header="" footer="" format="$Name" }%
* Raw title for the topic; empty if no title. Optional parameter for the topic name to get title from, defaults to current topic.
* Set TOPICTITLE = %IF{ "$'METATOPICTITLE{%DEFAULT{default="%TOPIC%"}%}'=''" then="%EXPAND{"$percentTOPIC$percent" scope="%DEFAULT{default="%TOPIC%"}%"}%" else="%METATOPICTITLE{%DEFAULT{default="%TOPIC%"}%}%" }%
* This produces the topic title if it exists, otherwise the topic name. Optional parameter for the topic name to get title from, defaults to current topic.
* Set LINK = [[%DEFAULT{default="%TOPIC%"}%][%TOPICTITLE{%DEFAULT{default="%TOPIC%"}%}%]]
* Syntax: !%LINK{"TopicName"}% Produces a link to the specified topic, but will display its title if available.
- Create file
foswiki/templates/edit.topictitle.tmpl
, to add topic title to edit form in pattern skin.
%TMPL:INCLUDE{"edit"}%
%{ add topic title to edit form, setting value to URL param 'topictitle' if present, otherwise setting to current title }%
%TMPL:DEF{"formtop"}%
<span style="font-size: 150%" title="Optional title for the topic; reference with %TOPICTITLE% which will return %TOPIC% if title is not set.">Topic Title:</span>
<input type="text" name="META:TOPICTITLE:%IF{ "$METATOPICTITLESET='true'" then="id1" else="id" }%:Name" value="%IF{ "defined topictitle" then="%URLPARAM{topictitle}%" else="%METATOPICTITLE%"}%" size="40" class="foswikiInputField" />
%TMPL:END%
- Create file
foswiki/templates/view.topictitle.tmpl
, to use topic title in breadcrumbs for pattern skin.
%TMPL:INCLUDE{"view"}%
%{ use topic title in breadcrumbs }%
%TMPL:DEF{"breadcrumb:topic"}%<nop>%TOPICTITLE%%TMPL:END%
%TMPL:DEF{"breadcrumb:parents"}%%META{"parent" nowebhome="on" prefix="%TMPL:P{"breadcrumb:separator"}%" separator="%TMPL:P{"breadcrumb:separator"}%" suffix="" format="$percentLINK{$web.$topic}$percent"}%%TMPL:END%
- Create file
foswiki/templates/foswiki.topictitle.tmpl
, to use topic title in window title.
%TMPL:INCLUDE{"foswiki"}%
%{ set the window title using the topic title }%
%TMPL:DEF{"windowtitle"}%<title>%TMPL:P{"titleaction"}% <nop>%TOPICTITLE%%TMPL:P{"titlesep"}%%BASEWEB%%TMPL:P{"titlesep"}%<nop>%WIKITOOLNAME%</title>%TMPL:END%
--
DavidAllen - 16 May 2014
MetaDataPlugin ... wooops, I can't see why you use it for this purpose.
Foswiki
itself can store topic titles just fine. The reason
DBCachePlugin is involved is just for the rendering speedup when it fetches the topic title in the
renderWikiWordHandler
.
NatEditPlugin is there for the edit interface and to store a topic title submitted during a
save
into the right place. This handler also deals with topic titles being stored in different places: either in a TopicTitle formfield or a TOPICTITLE preference setting. It also deals
with DataForms being added or stripped off during save and thus migration of the storage from preference setting to a formfield and vice versa.
So there is definitely more that needs taking care that I'd rather not encode in TML purely as you did.
Note that
NatEditPlugin has been added as a default core plugin to be released together starting with Foswiki 1.2.0. So whenever we talk about the edit interface, please use it as a baseline.
I've added an Impact and Implementation section above to outline the planned activities.
I've reset the DataOfCommitment. So the clock for this proposal starts ticking
now. If nobody raises concerns, the thing is accepted within 14 days.
--
MichaelDaum - 16 May 2014
TopicTitlePlugin will be added to the core.
--
MichaelDaum - 20 Jul 2021