Feature Proposal: [Short summary]

Motivation

Reasons why this feature is needed, and why it is suitable for adding to the next release of Foswiki.

Forms shouldn't just rely on ending in the word "Form" to be a Form but rather should use a Form (or other typing mechanism) to indicate what they really are. Calling a page *Form is insufficient and creates false positives: SEARCHs using a pattern match of the name to find forms can pick up non-forms. Without a proper mechanism to identify page authors will resort to ugly (and different) hacks to look at the content. If instead Form pages were tagged as such (e.g. were of the type, say, DataForm) you could do a QuerySearch to uniquely identify them.

See WebFormManagement which I use on my sites to group Forms with their associated topics.

• On Foswiki.org's Development web, some of these are Forms, but not all are.
• For instance MoreAttractiveForm not a form but it's name ends in Form

Description and Documentation

Description of what this feature should do

Instead of using rules such as "ends in the word Form" or "end in the word Template", topics should be typed using a META attribute.

This would prevent accidental typing such as CleanUpNewUserTemplate (not a template) and MoreAttractiveForm (not a form).

Examples

• CleanUpNewUserTemplate (bogus template)
• MoreAttractiveForm (bogus form)

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: MartinCleaver - 13 Mar 2010

Discussion

See http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2010-03-13,Sat&sel=76#l72

MartinCleaver	MartinCleaver believes that Forms shouldn't just rely on Form to be a Form but rather should use a Form indicating that they really are i.e. calling a page *Form should be insufficient	[10:46]
MartinCleaver	otherwise SEARCHs to find forms can pick up non-forms and you need to resort to ugly hacks to look at the content whereas if Forms contained a Form called, say, DataForm you could do a QuerySearch for them here's an example: http://foswiki.org/Development/WebFormManagement Some of these are Forms, but I bet not all are http://foswiki.org/Development/MoreAttractiveForm not a form it's name ends in Form But ! ISA Form
[11:34]
MartinCleaver	I could SEARCHing for content. Yuck.	[11:35]
MichaelDaum	MartinCleaver, of course. thats what the search should demo .... its inability to search for form definitions	[11:35]
MartinCleaver	it wasn't demoing that, it demoed that each Form has associated pageTemplate, ViewTemplate/Edit Template, List and Grid Edit	[11:36]
MichaelDaum	on foswiki.org DataForms seem to have a form attached to them with a field TopicClassification. most forms are classified AdminTopic	[11:36]
MartinCleaver	ugh	[11:37]
MichaelDaum	y	[11:37]
MartinCleaver	I could search content of "Name Type Size Value Tooltip Attributes" still yuck	[11:37]
MichaelDaum	no. search for TopicClassification='AdminTopic'	[11:37]
MartinCleaver	wouldn't work on my site and is not the definition of a form Name Type Size Value Tooltip Attributes is	[11:37]
MichaelDaum	then type/classify/tag these topics to make them findable	[11:38]
MartinCleaver	MartinCleaver believes that Forms shouldn't just rely on Form to be a Form but rather should use a Form indicating that they really are	[11:38]
MichaelDaum	y	[11:39]
MartinCleaver	<a name="l217"></a>ok, will write up in Development then <a name="l218"></a>ugh, should I use the Template "CleanUpNewUserTemplate" for my new topic? <a name="l219"></a>same problem	[11:39]

-- MartinCleaver - 14 Mar 2010

AFAIK the only reason for WEBFORMS (the current typing mechanism) is to "cache" form definitions and present them on the "choose the form" select in the edit page. This is confirmed by the fact that "WEBFORMS" only occurs in the core code in UI modules (ChangeForm and Edit).

As long as forms are defined in topic text, we would have no option but a global regex search to track them down. if you are going to start using META to tag a form, then you might as well move the form definition itself into META (something I suggested elsewhere).

One interesting option might be for a beforeSaveHandler to recognise when a plain text topic is a form definition and move the definition table into META at save time.

-- CrawfordCurrie - 15 Mar 2010

Today a form topic can be a topic with a lot of text and a table. We would have many falsely triggered "forms". I do not think this is possible in practical. And I have a hard time seeing where the problem is that we are trying to solve.

We do not have a hardcoded rule that says a form has to end with Form. You can call a form anything. So the assumptions that started this proposal are false. The Form suffix is a tradition and not at all a rule.

Templates however have a rule. Topic templates only matches the template path today if they end with Template. But we do not have such a rule with forms.

-- KennethLavrsen - 15 Mar 2010

'> And I have a hard time seeing where the problem is that we are trying to solve.

I want convention and method to retrieve the names of Forms and Templates that doesn't depend on their names or a content based SEARCH.

'> You can call a form anything.
'> Topic templates only matches the template path today if they end with Template.

Indeed, in Tasks web we call the Tasks Item Form "Item Template". Apparently for historical reasons.

Assuming WEBFORMS is 100% reliable method of retrieving forms used by content and usable by users, do you think that searching for a name is sufficient way to retrieve the names of Templates?

In that case, what about?

• CleanUpNewUserTemplate (bogus template)

'> As long as forms are defined in topic text, we would have no option but a global regex search to track them down.

As long as there is a core Macro to fetch them, I don't care if it has to be a global regex. A core macro would serve as an interface to ensure forward compatibility as we flex implementation.

'> if you are going to start using META to tag a form, then you might as well move the form definition itself into META (something I suggested elsewhere).

I think these would have to be phased in, but, yes, could do.

-- MartinCleaver - 15 Mar 2010

Not only forms and templates need to be distinguished from user generated net data.

Here's a crash course to outline the basic principles of the WikiWorkbench approach to wiki applications.

Let's call topics part of an application "ApplicationTopics" and make it a DataForm to be attached to every component of an application:

ApplicationTopic

Name:	Type:	Size:	Values:	Description:	Attributes:
TopicType	checkbox	3	some SEARCH to list all TopicTypes	Document type
TopicTitle	text	75		title
Summary	text	75		Short description of the role of this topic
WikiApplication	select+values	1	some SEARCH to list all wiki apps	Application this topic belongs to

Then bootstrap the type system

1. create ApplicationTopic and attach the form defined in the same topic
2. as well as TopicType, DataForm, DataFormAttribute, TopicFunction, TopicTemplate, TopicView (just to list the most common wiki application parts) and attach the ApplicationTopic form
3. set the TopicType of all topics created so far to 'TopicType'

You can now list all TopicTypes by querying for topics of type TopicType.

Now create new DataForms - lets say a new UserForm - and attach an ApplicationTopic form to it; check the "DataForm" value for the TopicType formfield. Do the same for TopicTemplates - let's create a new UserViewTemplate - and attach an ApplicationTopic form to it; check the "TopicTemplate" value for the newly created UserViewTemplate;

You can now list all DataFroms by querying for topics of type DataForm or TopicTemplate.

Let's extend the type system by creating two new TopicTypes:

First, WikiTopic: base class for all topics of a wiki: formfields are TopicType, TopicTitle, Summary; obviously an ApplicationTopic is a kind of WikiTopic, so to be precise all previous TopicTypes should be flagged "WikiTopic" as well.

Now let's create a TaggedTopic form with formfields: TopicType, TopicTitle, Summary and Tag; make the TopicType formfield a label for simplicity with a read-only value "WikiTopic, TaggedTopic":

TaggedTopic

Name:	Type:	Size:	Values:	Description:	Attributes:
TopicType	label	1	WikiTopic, TaggedTopic	Document type
TopicTitle	text	75		title
Summary	text	75		Short description of the role of this topic
Tag	tag	10

You can now create topics of type TaggedTopic and distinguish them from any other topic by searching for its type tag. Let's imagine, all TaggedTopics participate in a wiki app to render a tag cloud. Tags are collected from topcis of type TaggedTopic.

Now let's extend the type system one more time and we create a BlogEntry TopicType:

BlogEntry:

Name:	Type:	Size:	Values:	Description:	Attributes:
TopicType	label	1	WikiTopic, TaggedTopic, BlogEntry	Document type
TopicTitle	text	75		title
Summary	text	75		Short description of the role of this topic
Tag	tag	10
PublishState	radio	2	draft, ready-to-go, published	only BlogEntries in publish state are displayed on the frontpage
PublishDate	date	1		date the cronjob switches a BlogEntry from ready-to-go to published

As you can see BlogEntries already participate in the tag cloud application. The wiki app rendering the blog's frontpage will only list those topics that are of type BlogEntry.

WikiWorkbench relieves you from the hassle to bootstrap a type system for every wiki app by providing WikiApplicationTemplates. It is itself a wiki app to keep track of every component of your application. It comes with TopicTemplates for every kind of ApplicationTopic standardizing how it is documented. It generates a CompleteDocumentation listing all DocuTopics of a wiki app and keeps track every component has got the copyright of the wiki app attached to it...similarly to how our perl plugins are managed.

-- MichaelDaum - 15 Mar 2010

That looks like a good approach to handle virtually all distributed topics. And it serves as a better example than the current Faq and Tips topics.

-- ArthurClemens - 15 Mar 2010