Feature Proposal: Add structure to downloaded topics

Motivation

Simplify search, display and other cleverness

Description and Documentation

Eventually I'd like all topics in the core, and in extensions to have a 'topictype' - which in Foswiki terms is a Form.name.

Extension topics

initially though, if we get BuildContrib, and possibly configure to add Forms to all *Plugin, *Contrib, *Skin topics as they are uploaded or downloaded, we can add view templates to help us and our users.

for eg, the view template for a plugin (and its VarMACRO topics!) can have some boilerplate for URL's to report bugs, its enablement state, and if there's an update.

Specifically, I'm proposing to add %EXTENSIONWEB%.PluginTopic to a topic if its not already there - and if ./build.pl upload detects form info on foswiki.org, for it to grab it and add it to the topic too.

the EXTENSIONWEB defaults to SYSTEMWEB, but on f.o lets us customise further..

Other Core topics

I don't have specific Form names in mind, but if we can start with FoswikiCoreTopic , we can then use that to add view templates.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: SvenDowideit - 01 Aug 2012

Discussion

I fully support this feature requrest. However, before we can accept this proposal we need to define the form(s) and their fields.

Here's a starter derived from WikiWorkbenchContrib and ClassificationPlugin:

Typology

List of all TopicTypes, their inheritance among each and their use.

TopicType	ParentTypes	Comment
WikiTopic		the base of all content types; grants that there is a TopicType, TopicTitle and Summary field
ClassifiedTopic	WikiTopic	used as a base type for any topic that is about to be categorized and tagged
PluginTopic	ClassifiedTopic	do we need this? what about plugin vs non-plugin/core topics holding documentation or admin tools? these could be differentiated based on their category while their forms are all the same ...
PackageTopic	ClassifiedTopic	combines Extensions.PackageForm and parts of the inline Info Info Table of a package ... -> does that make sense? ...
DocuTopic	ClassifiedTopic	for topics holding documentation; this type is reusing the DataForm definition of ClassifiedTopic. That is: these don't require a DataForm of their own. This type grants that there is a named "documentation" section in the topic to be automatically extracted rendering the CompleteDocumentation

WikiTopic

Name:	Type:	Size:	Values:	Description:	Attributes:
TopicType	label	1	WikiTopic	Document type
TopicTitle	text	75		title of this topic
Summary	text	75		short description of the role of this topic

ClassifiedTopic

Name:	Type:	Size:	Values:	Description:	Attributes:
TopicType	label	1	ClassifiedTopic, CategorizedTopic, TaggedTopic, WikiTopic	Document type
TopicTitle	text	75		title of this topic
Summary	text	75		short description of the role of this topic
Tag	textboxlist	30		keywords for this topic
Category	text	30		categories this topic is field to

(note: in Extensions.ClassificationPlugin the formfieldsTag is of type "tag" and Category of type "cat")

PluginTopic

Name:	Type:	Size:	Values:	Description:	Attributes:
TopicType	label	1	PluginTopic, ClassifiedTopic, CategorizedTopic, TaggedTopic, WikiTopic	Document type
TopicTitle	text	75		title of this topic
Summary	text	75		short description of the role of this topic
Tag	textboxlist	30		keywords for this topic
Category	text	30		categories this topic is field to
...	...	...	...	...	...
...	...	...	...	...	...
...	...	...	...	...	...

PackageTopic

TODO

Taxonomy

List of categories to be used by ClassifiedTopics shipped with Foswiki.

TODO : we already have some categories in the System web and it might be a good occasion to improve the classification system.

-- MichaelDaum - 01 Aug 2012

Noting the issues that the JQueryAjaxHelper had with an attached form (Tasks.Item11329... Is this going to cause issues when copying topics from System into other webs?

If so, I still support this proposal - but we need to resolve that bug so there are no issues copying system topics into other webs.

-- GeorgeClark - 13 Aug 2012

I actually did not want to pre-define things - at this point even an empty Form would be more useful than stalling.

Basically, I don't think its worth getting into making a taxonomy because anyone that has deep feelings about it will disagree any classification that is different.

So, I propose to start by just

1. adding PackageForm (with web removed) to all the Extensions topics we have (and get BuildContrib to add one when creating a new one)
2. adding SkinTemplateForm and TopicTemplateForm to differentiate the 2 template types, thus making it possible to list on TopicTemplates in the CreateNewTopic UI
3. FormDefinitionForm to replace the WEBFORMS setting?
4. adding FoswikiSystemForm (alright, rename me) to topics installed from the _default web
5. adding FoswikiDocumentationForm to pretty much every other topic.

once that is done, we can look at the harder issues - getting a form on everything

-- SvenDowideit - 05 Oct 2012

It might be worth adapting the form names as used in WikiWorkbench applications:

• TopicView for VIEW_TEMPLATES and EDIT_TEMPLATES
• TopicTemplate for content blueprints
• DataForm for form definition
• DataFormAttribute for formfield lists

Note, don't get lured into creating too many DataForms most of which having the same structure. Distinguishing system tools from documentation topics is best done using a Category formfield that describes the content (vs the DataForm describing the structured data).

-- MichaelDaum - 05 Oct 2012

Changing to Parked - Needs a developer to adopt.

-- GeorgeClark - 19 Nov 2015

Commenting is disabled while not logged in