Feature Proposal: Topic display title

Create the possibility for a display title (the way a topic is shown as link) for every topic.

Motivation

-- 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"

• a couple of plugins already make use of a TopicTitle concept internally. These need to be touched to make use of official Foswiki perl apis to get and set topic titles
  1. WebLinkPlugin
  2. BreadCrumbsPlugin
  3. NatEditPlugin
  4. DBCachePlugin
  5. SolrPlugin
  6. ClassificationPlugin
  7. NatSkin
  8. PiwikPlugin
  9. FlexWebListPlugin
  10. ICalPlugin
  11. JQGridPlugin
  12. JQDataTablesPlugin
  13. ListyPlugin
  14. BlogPlugin

• maybe a few more

• 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

1. support storing a topic title in either in META:PREFERENCE called TOPICTITLE or in a TopicTitle formfield of a DataForm
2. display topic titles when rendering WikiWords
3. move handling of topic titles during save out of NatEditPlugin into Foswiki::UI::save
4. add a perl api Foswiki::Func::getTopicTitle for plugins to fetch the topic title
5. implement a %TOPICTITLE macro to be used in wiki apps
6. add a "change title" in the rename-topic dialog, including a "derive topic name from topic title" checkbox (see NatSkin)
7. review JQueryAjaxHelper to display topic titles when selecting topics (or users)
8. 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?

1. 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)
2. 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 '---+'
3. enhance URL syntax to support '^' notations
4. enhance =
   Searched:

= 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

1. create a topic using a TopicTitle only and deriving a TopicName from it (wikification)
2. change the TopicTitle of an existing topic
3. change the TopicName
4. change both TopicTitle and TopicName
5. 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 &#37;TOPICTITLE&#37; which will return &#37;TOPIC&#37; 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

Commenting is disabled while not logged in