Feature Proposal: the WEBFORMS preference is a PITA

Motivation

I want to ship wiki applications that can be "unwrapped" in an existing web, but the need to edit WebPreferences to add to WEBFORMS makes it impractical.

Description and Documentation

Make WEBFORMS optional.

At the moment, WEBFORMS is used as a list of the form definitions in a web (and also to reference forms defined in other webs. The proposal is simple: if WEBFORMS is defined, then use it, but is it isn't defined, then search the web for topics called *Form (the convention already in use for form definitions).

It may be reasonable to perform the search anyway, even if WEBFORMS is set.

Examples

• Set WEBFORMS = BlahBlah, Otherweb.ThatForm
• Set WEBFORMS =

-- Contributors: CrawfordCurrie - 19 Oct 2009

Discussion

Form definitions don't necessarily have to be located in the same web. Actually, best practice is to gather all implementation details as far away from the net data of a web, e.g. in some Applications.MyNewWikiApp subweb where normal users won't stumble over them.

So searching for xxxForm topics in all webs isn't scaling given the current standard search engine.

KinoSearchContrib analyzes WEBFORM settings to extract the formfields to be indexed. Not that this is a good idea, but something to take under consideration for your wiki apps.

A better approach than actively SEARCHing for form definitions on every edit again and again finding the same results is to remember where the form definitions are, that is have a database holding this kind of metadata about foswiki.

I don't like WEBFORMS either. And I don't use it in most wiki apps. WEBFORMS is only used to add or change a form to an already existing topic. However, first creating a topic and then attaching a form is not good. Nothing you'd explain normal users of your wiki app.

So another idea is to improve the process topics are created. You'd need a custom WebCreateNewTopicTemplate or any kind of "factory" to ease the creation of topics with forms already attached to it.

-- MichaelDaum - 19 Oct 2009

You are right, the problem isn't WEBFORMS per se, it's a crappy bit of code in ChangeForm.pm that could be written to use a SEARCH. However the problems you describe e.g. forms can be in other webs, remain. One approach would be to require the explicit importing of forms into the web namespace. For example, we re-interpret WEBFORMS to be like an IMPORT.

-- CrawfordCurrie - 22 May 2010

I like that IMPORT thingy. It is what's happening in WikiWorkbenchContrib: it allows to click on an install button to deploy a TopicType newly created DataForm definition into another web. It then comes with a custom creator to generate content of that type. Major drawback: creating topics is dislocated on several topics. That's not very comfortable.

What I was thinking of is that the "new topic" icon actually is a pull-down menu listing all TopicTypes that can be created in that web and then dive into an edit session right away, with the correct form and template specified in the url params already. Not sure how to make that feasible.

-- MichaelDaum - 23 May 2010

Another moderately interesting approach would be wildcards in WEBFORMS. For example,

Set WEBFORMS = Appweb.*Form, UserForm, %WEB%.*.*Form

where %WEB%.*.*Form is designed to pick up form types from subwebs containing deployed apps.

-- CrawfordCurrie - 23 May 2010

There are 2 competing issues here -

1. magically create a list of all topics that define a way to create /modify a new structured topic (not just DataForm based) - irrespective of how they get into the system (configure install, un-tar, cp, created via the wiki UI) Note: this is not an admin only task
2. allow the filtering of that list (either by IMPORT / EXCLUDE) for presentation to users.

What this implies is that the complete list of topic creators needs to include not just DataForm definitions, but also any non-form based topic/edit templates (possibly view template too, but thats less clear) - which can be either topic, or tmpl based.

Once we have this canonical list of possibilities, we want to be able to create a subset of them to present to a user depending on some context -

1. location - ie web, or web.topic (eg when editing a particular topic, you've restricted the choice to (atm) one particular DataForm/TopicTemplate/Edittemplate)
2. ACL - a user obviously has issues editing or creating a topic using a Form/TopicTemplate/EditTemplate that they don't have permission to view
3. url, time, random generator or some other - basic attempt to future proof

if there is a restricted admin for a web's WebPreferences, then the subset that can be applied to a web is clearly restricted, but if everyone can modify the replacement for WEBFORMS, then that setting becomes more of a shortcut for commonly used topic definitions.

The main reason that we've had this pre-registration of options, rather than a query, or wildcard, is that like Group definitions, we don't want to go out and SEARCH all the thousand webs. For groups, we've currently made (the imo dodgey) choice to limit groups to one web.

I suggest that WEBFORMS is an outdated concept that doesn't represent the entire gamut of TopicTypes that exist in foswiki, and that we should add a new 'setting' TOPICTYPES that defaults to a dynamic list of all DataForm, NewTopicTemplate and EditTemplate that exist in the foswiki (and that the user can view), but which can then be set via WebPreferences, and META:FORM{name="ItemTemplate"} to provide hints of the AutoViewTemplate style.

Icing on the cake would be to leverage FoswikiSettingsWizard to simplify the selection of the subset - this could be used both for WebPreferences, and for the add/replace form functionality.

-- SvenDowideit - 23 May 2010

... let me clarify.

What we want is to come up with a more intelligent way to support "add form" and "change form" (during edit) other than the current WEBFORMS mechanism.

Related question is setting the DataForm during topic create time which is less of an issue as respective url parameters allow to set an arbitrary form defined anywhere. While wiki apps developers are encouraged to write their apps in a way the DataForm is set during topic create time (and better don't require choosing a DataForm later), the operations to add or change the form of an already existing topic have to be supported.

So improving the topic creation process is actually not the main focus here. Let's discuss this actually quite complex issue on a separate feature proposal.

Now, central question here is: how does the engine get to know which forms exist without using a WEBFORMS-like preference setting maintained manually? Or phrased the other way around: why doesn't the system know which DataForms are defined somewhere and can we change this?

How about using some kind of registry database updated during save?

-- MichaelDaum - 24 May 2010

Can we distinguish data form topics from other topics? Now we have to say - using WEBFORMS - this is a data form definition.

-- ArthurClemens - 24 May 2010

As Arthur says, you can't easily distinguish a topic intended to be a form, and a topic that happens to contain a table that looks like a form schema. Perhaps if the form definition table were more unique....

To summarise the proposed mechanisms:

• WEBFORMS
• Some scheme based on topic naming e.g. *Form
• Some scheme based on a SEARCH, possibly caching the forms you found last time
• Dynamically maintained registry, based on scraping topics during save

-- CrawfordCurrie - 25 May 2010

I would say that the simple, easy to understand for the user, fully compatible way would simply be to allow the wildcard character * in the form names for WEBFORMS

The _default web and the webs we ship would be changed so the setting is

Set WEBFORMS = *Form

People can then continue using their old webs as they are. Example..

Set WEBFORM = SomeForm, SomeFormThatDoesHaveFormAtTheEnd, Hello, RecordMaster

And naturally the mix is allowed so people can extend existing webs to take advantage of the new feature

Set WEBFORM = SomeFormThatDoesHaveFormAtTheEnd, Hello, RecordMaster, *Form

That would give the best of everything.

Performance it means a small hit when you go into the change form page. But this you do rarely. Normal view and even normal edit will not load all the forms.

-- KennethLavrsen - 08 Jun 2010

Implementing the data form in the same web as the net data the user creates is not really a best practice even though it is a pattern we see a lot.

Adding a wildcard logic to WEBFORMs is indeed only of moderate interest as it doesn't really solve the problem. Instead it adds a dynamic search to the "add/change form" dialog.

We already have too many searches of that kind trying to analyze the topics again and again. Things like rename/move/delete, backlinks, weblists, topic lists and the like treat the topic data like a foreign country that needs to be conquered repeatedly. That's really bad design. I'd prefer to see the foswiki core being more "informed" about what data it controls.

-- MichaelDaum - 08 Jun 2010

I have created a draft of a data forms management page. Something like this probably also exists in the WikiWorkBench.

The idea behind this page is:

• Data forms are stored in a list (perhaps in META of the overview topic).
• Data forms are listed if they themselves have a form named System.DataForm.
• Other forms can be manually added to the list and stored.
• Wiki apps that show a list of topic types consult that stored data.
  • Probably a name for the topic type needs to be stored somewhere - if you want to create a new topic of type "Project" for instance.
• The "change (add) form" page also consults this data, but adds to it the forms that are listed in WEBFORMS to be compatible with older installations that do not have forms.

Creating topic types / data form topics can be done in a new way and an old way:

-- ArthurClemens - 22 Jan 2011