Feature Proposal: Allow hidden topic-specific (and other) settings

Motivation

Any preferences or other settings that are specific to a topic must be put into the topic text. This is not only distracting to the reader, but also opens up the possibility that these are accidentally changed during an edit. Hiding these settings in HTML comments avoids seeing them in the rendered topic, but the settings are still prominently visible during edit.

SupportFormsForSettingPreferences, if used, makes this situation worse by always exhibiting these settings in the form.

Goal: Provide a mechanism to associate settings with a topic which are not edited in the white board application nor visible in the rendered text.

Description

Adds a mechanism of defining settings or preferences that are stored in metadata and edited with a specific edit application.

The proposed implementation adds a link to the more... oops that allows to edit topic-specific settings.

-- ThomasWeigert - 10 May 2005

Impact and Available Solutions

In SVN 4285-4288.

Documentation

To be provided.

Examples

http://develop.twiki.org/~develop/cgi-bin/view/Sandbox/ViewTest gives an example of defining topic specific settings.

Implementation

After the decision to provide simplified editing of preferences using the PreferencesPlugin rather than the mechanism discussed in SupportFormsForSettingPreferences, the mechanism of setting preferences in forms became redundant. Replaced this by the ability to store settings in metadata, using

%META:SETTING{ name="...." title="...." value="...." }%

An editing application is provided and accessible from the more oops. Syntax is as with ordinary settings.

Discussion:

[Arthurs comment moved to SeparateWhiteBoardEditFromFormEdit. - SH]

Thomas - as long as you are exploring a mechanism to selectively hide form-based metadata, I wonder if it could be implemented as a generalized option for any form field? I have long thought it would be useful to be able to hide certain form fields in view mode. Perhaps we could add a "hidden" attribute for meta data?

-- LynnwoodBrown - 10 May 2005

Lynnwood, just to verify: you are suggesting to add an attribute "H" which causes the field to be editable in the form, but not to be shown when the form is being rendered?

-- ThomasWeigert - 11 May 2005

No, Lynwood proposes TWikiFormWithHiddenType feature, analogous to TWikiFormWithLabelType. I think this is a good idea. This is something else than the hidden preferences settings.

-- PeterThoeny - 11 May 2005

Hmmm. I guess I don't understand. We cannot edit the form field, nor even see it during editing. But it would be shown in view mode? How does it even get into the form? Just from the defining table or initializing template? This would be to take some of the cruft out of the editing of the form?

Note that if you want a hidden field (similar to TWikiFormWithLabelType) you would not use the attributes for indicating such a field, but instead introduce a hidden type...

-- ThomasWeigert - 11 May 2005

On hidden preferences settings, I see it useful for user preferences and topic preferences. But it is not applicable for WebPreferences and TWikiPreferences since there we want to have preferences settings mixed with nice documentation.

To use a consitent terminology I suggest to name the meta data %META:PREFERENCE{...}% instead of META:SETTING

-- PeterThoeny - 11 May 2005

Agreed. This is only meant as an option for situations where we do not want to show the settings (where we currently use the HTML comments to hide it, for example). For visible preferences I wrote the PreferencesPlugin to edit them based on the original way, with documentation and preferences intermixed. There the goal is to make the settings prominently visible while making editing convenient.... _Done. SVN 4289. --TW

-- ThomasWeigert - 11 May 2005

Sorry, what's the difference between

%META:SETTING{...

%META:FIELD{attributes="S"...

-- CrawfordCurrie - 11 May 2005

I have removed %META:FIELD{attributes="S"...}%. I think that was an unfortunate mixture of different purposes. The form application has really nothing to do with settings. This confuses content of the form application with configuration of the TWiki platform. I strongly feel that these must be separated. That is also the reason why I don't like to see settings in the whiteboard application (except for the *Preferences topics, the sole purpose of which is to do settings). In short, the number of settings has not changed...

-- ThomasWeigert - 11 May 2005

While I totally agree with the idea of separating preference settings from text, I really don't like the idea of creating a new type of data in a topic. We already have text, form-meta-data, and attachments, all handled differently, but all built on the same base types. Now we have preferences, which are very very similar to forms meta-data, as yet another collection type.

Personally I think that rather than twekaing in changes like this we need to bite the bullet and go for multiple forms in a topic. In that case, the "Preferences" form would be one of several forms and could be handled by many of the same mechanisms, avoid duplication.

If we are going as far as adding meta-data types, please please please consider using %META:FIELD{form="_preferences".... or similar instead of %META:PREFERENCE. At least we would have a chance of rationalising support in the future. Note: I am not mixing the form application with the preference application here; I am simply trying to rationalise the way meta-data is stored in topics, and make sure we don't duplicate code unneccesarily.

-- CrawfordCurrie - 11 May 2005

I think preferences have nothing to do with forms. A form is a separate application. It should come as no surprise that preferences thus warrant a different application.

Having multiple forms does not change the situation. In my applications, I don't want to see the settings during normal user editing, not in the whiteboard text, nor in the form, not even in a second form.

In my opinion, taking preferences out of the form application is an important step forward. Hey, this might even lead to a real preference editor...

I think calling it %META:PREFERENCES for now is not causing a problem with rationalizing it later, as this representation is not user visible. However, I am convinced treating this as a form field is just wrong.

Note that I did experiment with keeping the old S attribute but the form wipes out data that is not in the schema. So it must be shown on the form. I tried to relax that, but this caused problems in that then it was possible to have data in the topic that could not be edited any longer (by changing the form).

-- ThomasWeigert - 11 May 2005

On your multiple form issue, I have basic code for that, but am still struggling with the use cases to motivate final design. Maybe there should be a feature request with detailed requirements so we can discuss those?

-- ThomasWeigert - 11 May 2005

It seems that this discussion is diverging into two discussions: one related to hiding form fields and the other related to the larger question of handing preference settings versus form data.

On the matter of hiding form fields, let me just clarify that Thomas correctly understood my suggestion: having a form field attribute which "causes the field to be editable in the form, but not to be shown when the form is being rendered." My intent is simply to have an option to simplify the rendered view. There might also be a parallel option to hide the whole form in rendered view.

-- LynnwoodBrown - 11 May 2005

Lynnwood, I have implemented this feature. Please create a FeatureRequest and I will check it in as a solution to that request...

-- ThomasWeigert - 12 May 2005

assuming TWikiFormWithHiddenType is that FeatureRequest, i'm marking this ReadyForMerge

-- WillNorris - 05 Jun 2005

How do you retrieve such a preference setting? Should I be able to write &pcnt;META:PREFERENCE{name="ALLOWTOPICREAD" topic="ApplicationPermissions"}% ?

-- MartinCleaver - 10 Oct 2007