Feature Proposal: Add structure to downloaded topics
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.
initially though, if we get BuildContrib
, and possibly configure to add Forms to all
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
state, and if there's an update.
Specifically, I'm proposing to add
to a topic if its not already there - and if
detects form info on foswiki.org, for it to grab it and add it to the topic too.
, 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
, we can then use that to add view templates.
-- Contributors: SvenDowideit
- 01 Aug 2012
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
List of all TopicTypes, their inheritance among each and their use.
(note: in Extensions.ClassificationPlugin the formfieldsTag is of type "tag" and Category of type "cat")
List of categories to be used by ClassifiedTopics shipped with Foswiki.
: we already have some categories in the System web and it might be a good occasion to improve the classification system.
- 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.
- 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
- adding PackageForm (with web removed) to all the Extensions topics we have (and get BuildContrib to add one when creating a new one)
- adding SkinTemplateForm and TopicTemplateForm to differentiate the 2 template types, thus making it possible to list on TopicTemplates in the CreateNewTopic UI
- FormDefinitionForm to replace the WEBFORMS setting?
- adding FoswikiSystemForm (alright, rename me) to topics installed from the _default web
- adding FoswikiDocumentationForm to pretty much every other topic.
once that is done, we can look at the harder issues - getting a form on everything
- 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).
- 05 Oct 2012
Changing to Parked - Needs a developer to adopt.
- 19 Nov 2015