create new tag
, view all tags
When the new TWikiForms system was written I had in mind that using it for editing settings should fall out fairly easily. I've now started to really see what's involved. Idea at present is:

  • An field in a form definition can be declared to be a setting
  • These settings would be added to preferences after the existing mechansim - logical as forms appear at the end of topics.
  • The form definition table syntax would be extended e.g. with an extra optional column, say Flags, is this had a S in it, the field would be considered as a setting.
  • The code changes for this seem to be pretty minimal


  • On personal pages in Main, at least for the commonly used settings. Note that this would be easy to do for new sites, but would require some thought for existing sites.
  • On preferences pages - some multi-value settings would have to be represented by text or textarea unless new form types are added, possibly by extending the plugin API to allow for new types.


-- JohnTalintyre - 23 Jan 2002

I've done a first cut implementation of this and it seems to work very well. You can specify that a form field is a setting and it's picked up for user page and will also work for Web and TWiki preferences. I've haven't yet added to work for current topic.

I've also written an experimental extra plugin handler, so that extra type of fields can be added for form handling and existing ones can be overridden. Form at present is

renderFormFieldForEditHandler' # ( $name, $type, $size, $value, $attributes, $output )

Probably also need a function to cut in when data is saved.

What do people think? Also it would be nice for the plugin to know if the client uses Javascript, anyone know of a clean way to do this? One nasty way might be for Javascript to cut in and re-request page, so start with a control that doesn't require Javascript, but if it's present, bring up a page with Javascript. If a Session is being used (SessionPlugin) then this step would only need to be done once.

-- JohnTalintyre - 04 Feb 2002

Sounds like a good idea - not clear whether this will replace the old 'Set FOO = bar' type settings, or coexist with them, but it does sound neater, particularly where a multi-valued field can be used to allow only valid settings. I'm not sure why JavaScript detection is needed though.

There are certainly other Wikis that have form-based settings pages for per-user prefs, so it would be good if TWiki could move in this direction and improve usability, even in a small way.

-- RichardDonkin - 04 Feb 2002

I've written it so that the old 'Set FOO = bar' format still works as well - useful for compatibility and also for adding properties that haven't been put in the forms. I've done a little control for a multi-value field - this doesn't work without Javascript, so really needs to default to something that does if Javascript isn't present.

-- JohnTalintyre - 05 Feb 2002

On EvEm I've placed the form before the text area. TWiki allows me to do this. It's A minor point, but an example of what you can't just assume.

-- AndrewTetlaw - 05 Feb 2002

I realised that this was a possible problem. The META data is structured so that the form data appears after the text as well. However, I'm not sure this matters too much as people wouldn't generally use two methods for the same setting.

-- JohnTalintyre - 06 Feb 2002

Information on Plugin changes for forms now in ExtendingFormControls

-- JohnTalintyre - 23 Mar 2002

I find that forms are quite heavy to be used by "normal", dummy users, though very useful. I would like to have your opinion about embedding forms into topics

-- FrancoBagnoli - 25 Mar 2002

In what way are form heavy for "normal" users?

-- JohnTalintyre - 25 Mar 2002

I'm experimenting twiki as a content manager system for my department (University) and also for nonprofit sites. Most of my users are not expert, in the sense that sometimes even a caps lock key pressed may block their activity...

Well, I found no problem in explaining them the twiki concepts, but still they find some problems in creating pages from scratch and respecting all kinds of "strict formats".

I solved most of their problems by inserting forms (with javascript checking) on the WebHome topic of each web. For instance, a news web contains topics whose name has to start with a date, so to easily filter and sort them. I obtained all sorts of date formatting, until I wrote a simple front-end with menus. Now I would like to set up a web for all kinds of documents that have to be filled up.

I was also able to let them use forms, but explaining them how to set up a new form is rather difficult. Moreover, if I need a form in just a few pages (or just one page) just to have "menus", they are quite heavy...

-- FrancoBagnoli - 25 Mar 2002

It sounds as if this is mostly about the creation of new forms, rather than the use of an existing form. Certainly TWiki lacks wizards to do this. A plugin to do this might be the best bet.

-- JohnTalintyre - 25 Mar 2002

The current format for defining a form is:

Name: Type: Size: Value: Tooltip message:

is suggest adding to this so we have:

Name: Type: Size: Value: Tooltip message: Attributes

Attributes would be optional and initially only one would be supported - S for settings.

-- JohnTalintyre - 09 Apr 2002

I've implemented this and am happy to add it to CVS if there's a demand. The most useful aspect is that users can set the preferences using the form.

-- JohnTalintyre - 11 Apr 2002

Go for it, sounds very useful! As the TWiki UI improves, there will be more and more settings to tweak (e.g. see JavascriptBasedEditor where you can now select toolbar position).

-- RichardDonkin - 12 Apr 2002

The attributes would also be useful for some of the other features I have been looking into including:

R - required field, must not be the first (default) value in a list, or must not be blank for text fields. D{value} - default value F(TEMP=template;ERR="text"} - required format for field

This way a phone number field can use:

RD{"(321) xxx-xxxx}F{TEMP="(###) ###-####";ERR="Please enter your phone number as in (555) 554-5555")

When its submitted, if there is a format error, the error text is displayed and the user gets another chance to change it.

The attributes would have to be TWiki expanded first to allow %XXX{}% substitution first.

-- JohnRouillard - 12 Apr 2002

Forms for user settings are more user friendly. Points to investigate:

  • Should all preferences settings be converted?

  • How to handle a form setting that is also present as a Set= setting?
    • Simply ignore one or the other -- possible confusion
    • On topic save, sync the Set= setting with the form setting value?
    • The latest SiteMap depends on WebPreferences settings to list the web info (color, description, use to...) automatically on the site map table. The SEARCH in site map can do only one or the other. Other dynamic content aggregation might depend on Set= settings as well -- possible confusion
    • The ScriptToCreateNewWeb will patch the WebPreferences topic. Need to decide if to patch the Set= setting or the form setting or both.

  • Any performance hit?
    • Preferences are read and cascaded with each topic view. Any double processing of evaluating values might have a performance hit.

-- PeterThoeny - 12 Apr 2002

Peter, as always, you raise some good points. I've currently written it so that the form settings overrides the Set= syntax. I'm inclined to keep this but re-write the Set= setting as you suggest above, less room for confusion (I hope). I'll have to look into the dynamic content aggregation, I hadn't realised it would be an issue. The ScriptToCreateNewWeb issue could potentially be left to later, as forms for settings don't initially have to cover all settings.

I'm not sure on performance hit, at present only covers TWiki and Web preferences, how are these cascaded?

-- JohnTalintyre - 15 Apr 2002

I'd like to see the form settings write back to the Set= syntax as well as to the metadata - that way we don't end up with data out of sync. If there is a TWiki.pm function to write a setting to a page in both Set and metadata format, it should be fairly straightforward to have the ScriptToCreateNewWeb use this.

-- RichardDonkin - 15 Apr 2002

With form-based preference settings, things could be made even easier by also adding more VARIABLES to the existing templates. Just replacing twikiHome.gif with %LOGO% (for logo filename) and %LOGOTEXT% (for img alt attribute, with %WIKITOOLNAME% as the default), is a major convenience. There are lots of hardcoded or unused HTML attributes in twiki.tmpl and view.tmpl. that updating those two to make a big difference (eg: body bgcolor plus add text amd link attributes; table widths and bgcolor; since there are font tags, size variables).

Possibly not for forms, but related, HardcodedEnglishText is also interesting, useful for same language changes as well.

Other quick template changes that work with these, but aren't form-related, continued in SimplerDefaultTemplates...

-- MikeMannix - 18 May 2002

It seems to me that a simpler solution here would be to rely on something like the EditTablePlugin; you could just have a table with all the variables, and then clicking edit table would allow you to change any of the variables. Can't get any simpler than that (from the user point of view)?

-- ThomasWeigert - 02 Jun 2002

_What follows is sort-of brainstorming and sort-of specification by use-case. I really should refactor this into something about how TWiki is too programmer oriented and need better user level functionality if it is to be a product._

This is all on the way to making Twiki look more like a product and less like a "hackers delight", where the underlying mechanisms are visible to the end user. ALERT! Hence it is an important aspect of Usability. See also TooUglyForNonTechnicalUsers.

There are really two classes of settings and a number of subdivisions, and it really is important to differentiate between them or there is going to be a mess.

The first division is between settings that are access control and those that are options.

Lets look at access control first.

If we look at file systems, the access control information is not stored in the file itself, but "out of band". (In days long gone by some OSs did store it inband, but had file access mechanisms that didn't let the user see it. Having them stored seperately, and in particular having the access control info read before the data store is opened, is both simpler and more secure.)

I appreciate that Twiki alread has in-band information that the user edit can't see, the last author and revision "header". Lets face it, that is just a performance enhancement. It could be extracted from the RCS subsystem. I'm trying to differentiate between a few thigns here. The user doens't need to alter that "header", the system does it an only the system should. In particular, it has to be in a constrained format.

In absolute terms, so should the access control. We don't want the user editing

   * <nop>Set ALLOWTIPICHANGE <nop>= <nop>TwikiAdminGroup

when he means

   * <nop>Set ALLOWTOPICCHANGE <nop>= <nop>TWikiAdminGroup

MegaTwiki addresses some of this, but since those lines can occur in the topic, the user can edit them in anywhere he desires. The authorization edit tool may pick them up later, but the damage is now done.

Having the access control in-band means that many things can go wrong.

  1. A user can edit the setting to junk because its 'just text' and there could be a typo. See above.
  2. A user can change the setting to make it inaccessible - including unviewable as part of the edit-view-commit process - by himself.
  3. A user can give away control.
  4. having access control in-band is programmer-oriented not user-oriented, and makes the interface ugly. See TooUglyForNonTechnicalUsers for further discussion.

I've seen and worked with a number of OS access control systems that have run on mainframes and minis sicne the 1950s. Many were bad ideas. The one UNIX has is elegant, fast and simple - provided you understand about "sets" and "groups" and are using the Berkeley semantics rather than the old V7/SYSIII semantics.

Perhaps the "out of band" system that is most suitable was the one used extensively by QNX in its early days, and is echoed by Apache. In each directory there is an "invisible" (at least to the application users) file. For Apache it's the .htaccess file.

The QNX version had much in common with the way that TWiki sees things. Start with the the most local and move to the global.

The only interface MUST be forms driven like in MegaTwiki. The users must not see what's "under the hood".

Under the hood the access for a file UsingFormsForSettings.txt would first look for ".acc.UsingFormsForSettings", then ".acc.%WEB%" (since webs don't have WikiWord names), then ".acc.%TWIKIWEB%".

Hopefully there will be sensible defaults shipped that correlate to groups. One might imagine a number of subject-secific webs (i.e. forums) that are restricted to memebrs of those forums.

Or perhaps there are other more "efficient" ways to do this.

  • There could be a co-process that caches the access control information.
  • There could be a single file per web (or access heirarchy) that contains all the information for that web. For example:

   DENYWEBVIEW = < list of Users and Groups >
   ALLOWWEBVIEW = < list of Users and Groups > 
   ALLOWTOPICVIEW = %<nop>WEB<nop>%Group all 
   DENYTOPICCHANGE = < list of Users and Groups >
   ALLOWTOPICCHANGE = < list of Users and Groups >

   ALLOWTOPICVIEW = %<nop>WEB<nop>%Group 
   ALLOWTOPICCHANGE = < list of Users and Groups >

This is, so to speak, the "MicroSoft" syntax.

Note the deny,allow order, just like in Apache. Which makes me think that with a different syntax, some Apache code, or at lest a CPAN module that manipulates such format, perhaps Apache::Config, cold be used.

Or perhaps avoid any new, heavy code modules and take the MegaWiki code that edits the present format, only put it in a separate file. Perhaps some kind of table editor. (This of course emans that the tables have to be correctly initialized when the web is created and when the topics are created, but you knew that anyway, didn't you wink A per file or per web access control file would then be the simplest approach.

Of course because the access control information is stored out of band, it will have to be edited by means of some form.

The logic behind the form will prevent unreasonable settings, will make sure that the users or groups do exist and so forth. We see similar thigns in the UNIX CHMOD command when it uses symbolic names, echink against /etc/passwd and /etc/groups.

I said two main classes, didn't I. You thought I'd forgotten about the other.

It is the user visible and user controlable settings. What makes them different is that the user sees the name and value,

These fall into four divisions.

  1. Variables where values are simple on/off, such as RELEASEEDITLOCKCHECKBOX, DONTNOTIFYCHECKBOX, NOSEARCHALL etc
  2. Variables with a constrained but statically determined set of values, such as EDITBOXHEIGHT whch takes a numeric value that has to fit the screen.
  3. Variables that take an arbitrary string, such as the copyright notice, the e-mail and logo settings.
  4. Variables with a constrained set that needs to be generated dynamically. FINALPREFERENCES is a good example of one of the more difficult ones, but usually they will be things like the users and groups.

This last division can be further subdivided into

  1. Variables that take a single value
  2. variables that can take multiple values

We can also distinguish different TYPES of variables that are controlled

  • The administrative control over system configuration variables, the site and web settings, as well as other variables that need to be standardized such as the default LOGO, the default SKIN. In addition, each skin or other plug-in should also define what variables and values it uses for this level of control.
  • Variables that can be over-ridden
  • Variables that can be newly created. User topics and and many other topics may require these.

I'm going to try to derive a diagram showing some of this.

-- AntonAylward - 31 Dec 2002

The implementation I mentioned higher up is now in a fairly good state and I'll add it to CVS after the BeijingRelease. It offers:

  • compatibility with the current method
  • uses the existing form system
  • form system controls can be extended by plugin e.g. I've done a multi select that can feed of user topic

-- JohnTalintyre - 01 Jan 2003

I am trying the following approach:

  • Have structured data represented with structure intact. This may not be HTML, but something like YAML (http://www.yaml.org) i.e. it should be easy to do in-place edit if required.
  • This structured data would be hidden in normal view. Instead, you provide good reporting capabilities (integrated with form editing capabilities) to display the data.
In essence, it should allow us to automatically recognize structures such as lists (which twiki does, already), and add appropriate editing buttons for those structures - just like EditTablePlugin. In any case, my current interest is to allow good integration between tables (in DB) and twiki, and a good handle on reporting of data.

Please see my further comments in TemplateToolkit - I have attached a plugin there. (And another enhancement to PollPlugin at PollPluginDev - as an experimentation with this concept.)

And I would like to test out your enhancements. Is a version available for Dec 2001 version of twiki?

-- VinodKulkarni - 08 Jan 2003

My implementation is on the latest CVS codebase and should be checked into CVS once the BeijingRelease is out. If you want it sooner I can sent you a ZIP.

-- JohnTalintyre - 10 Jan 2003

The time has finally come - I'm now going to add this to CVS.

-- JohnTalintyre - 14 Mar 2003

Now in CVS. See early form for WebPreferences at WebPreferencesForm - needs to be attached to this topic and registered as a form. Note this uses features that work best with ExtendingFormControls.

-- JohnTalintyre - 14 Mar 2003

John, Peter - can you guys actually use this somewhere so we can see it in action? will this be a replacement for the existing * Set method?

(i;m still not sure where this feature fits in)

-- SvenDowideit - 13 Jan 2004

Good point. Already in code base, should be able to use today. Obvious starting place is to use for Web Settings. Please note that Set still exists and has some advantages e.g. lower overhead to add.

Please note that this facility works best with FormFieldsPlugin in place.

-- JohnTalintyre - 13 Jan 2004

Question - why:

            if( $attributes && $attributes =~ /[S]/o ) {
                prvAddToPrefsList( $key, $value );
Why not:
#            if( $attributes && $attributes =~ /[S]/o ) {
                prvAddToPrefsList( $key, $value );
#            }

? Did you do this and find problems? (The latter is significantly more powerful, when added with the ability to add random extra settings without the need of a form)

-- MS - 02 Feb 2004

If I understand correctly, the code change suggested by MS would mean every form entry counts as a TWiki preference (setting), at least on a topic for which this makes sense. An interesting question, which I don't have a ready (convincing?) answer to, but I'll try. In current usage this change would save an extra column in the preference page forms. However, I think the explicit "S" is probably a good idea, as it makes explicit that there is something different about a given form field.

-- JohnTalintyre - 02 Feb 2004

Yep, that's pretty much what I was asking - you've classified Meta data into stuff that can be settings and stuff that can't be settings. I was curious as to why. (Especially considering that if you include the 1 line change I made regarding allowing settings in topic pages that including metadata in a topic - such as this one becomes as simple as:

  • %TopicClassification%
  • %TopicSummary%
  • %InterestedParties%
  • %AssignedTo%
  • %FeatureStatus% - I know not part of the form below, but consider it was. (eg options: Proposed | Implemented | Done | etc )

This strikes me as by far and away far more "wiki" than most other approaches to meta data extraction. (It lacks some advantages of course of the other methods)

I've made this change and just wondered if you had a good reason why you'd made this separation, or had just put it in early. BTW, I note there's not been a huge amount of feedback in actually using this - personally I think it's an extremely useful feature.

This minor change above also removes the restriction on needing access to a WebForm - in the same way a normal setting doesn't rely on it.

  • Demo : http://chaos.owiki.org/TestTopicSetSkin . Allowing arbitrary meta fields to be appended to a topic without a form definition would allow this to be more flexible. (And you also end up with a preferences page which is more like other wikis)
    • Further update - if you do allow this, this allows people to customise how web form infomation is rendered in a very clean, user intuitive manner. (You include in the text, and the values then get punched in. Again, this then allows further end user customisations)

-- MS - 02 Feb 2004

and I think this leads to something i wanted years ago.. WebForm data entry that is displayed in FreeForm (ie fill in a form letter, and ge out a letter (without displaying the WebForm)) I would like to see this idea go another step - the tabular WebFormView is the default, but you can define a seperate the rendering of a webform (so there is a META:FORM definition, and a META:FORMVIEW definition (if there is no META:FORMVIEW we fall back to how it works now))

and if we add META:FORMEDIT as a definition for the edit view we get to do workflows (by keeping the META:FORM the same, but changing the META:FORMEDIT, and the META:FORMVIEW as we move along the process)

mmm, workflow again.. I think i'm obsessed

PS - Michael smile

-- SvenDowideit - 03 Feb 2004

I've implemented FreeForm entry on my wiki. Look for the FeatureDevelopmentWizard . It's only for creation at present, but there's absolutely no reason it has to stay that way given these changes. Rather than add an extra META: definition moving the creation/modification of these things server side, I'd probably simply add it onto the SKINSECTIONS page as an extra named section - I could then fail back to pulling in an edit/display named sections from the form definition. (For webforms, and a default web template for content)

-- MS - 03 Feb 2004

mmm, first reaction to the SKINSECTION is that it would stop me from using the FORMEDIT and FORMVIEW definitions from different frontends... like a native view&edit program (I'm starting to think about writing a VooDooPad like tool for Windows (I emailed Gus and he indicated that porting it would not be worth it for him as he uses lots of OsX specific systems) using WinForms and .NET - and I will need good WebForm support.

-- SvenDowideit - 04 Feb 2004

I've put example usage of this in WebPreferences, unfortunately this is set to be only editable by TWikiAdminGroup, which means that this feature can't be tried by others. So need to relax this permission or have another (less stable?) Web.

Note that could do with FormFieldsPlugin installed to show real benefit. Still need to explore MS suggestion from above that all form entries could be treated as settings; I have a feeling he's onto something there - just can't completely get my head around it.

-- JohnTalintyre - 13 Feb 2004

Pure brainstorming:

setting/meta comment
TWiki TWiki.cfg, TWikiPreferences  
wiki   not implemented but seen some interest in TWikiFarms
web WebPreferences  
SubWeb not implemented implemented in MegaTWiki
topics TopicsMetaData  

to me all the above are the same thing (just called differently: config, Prefs, Meta ) and could be implemented using the peace of code combining TWikiForms and EditTable in one single Plugin.

Some folder reorganisation would be necessary though, but for me it would simplify things: |*folder*|*file*|*previous name*

TWiki Prefs Twiki.cfg
wiki Prefs TWikiPreferences
web Prefs WebPreferences
subweb Prefs  
.xx.. Prefs  
sub...subweb Prefs  
topic Prefs, TopicText, Attachements, PrerenderedHtml(Cache).... embeded in TopicText and in Pub folder

Having meta/prefs separated from the topics text and handled by a Plugin would make things easier for somebody to implement an other Plugin to store meta/prefs in a database or ..... use an other Plugin to keep the * set Variable Value syntax.

It looks nice to me but i do not know how much is involved ? Search ... As said above just brainstorming. If this in not the proper place for it please move it somewhere else.

-- MarcelTrap - 10 Apr 2004

This is ready to go on twiki.org for user preferences, all it needs is for one of the TWikiAdminGroup to turn it on! Would somebody please:

Then anybody who wants to use the forms for preferences then

  1. edits their user page
  2. 'Adds' UserPreferencesForm to their page
  3. saves
  4. and then edit again to use the form.

After a suitable shakedown period this could be added to the new user template.

I'm impressed by how well this works. My only beef at the moment is that the "tool tip" column is actually a tool tip -- it only displays when you hover over the form label. It would be better (in this context) to have it shown as another column to the right of the setting (or perhaps as a row above/below).

-- MattWilkie - 22 Apr 2004


You can now select a style to view twiki Codev or Sandbox: I added TWIKISTYLETOPIC to the form.

In your user topic, in the web form, select BlueStyle, or:

  1. create a new topic with css definition in Sandbox
  2. add it to UserPreferencesForm
  3. change your user topic to select the new style topic
  4. go back to Sandbox or Codev

-- ArthurClemens - 22 Apr 2004

moved docs to TWikiForms

...first kick at the docs can. Pleasefix/update/mangle as necessary. -- MattWilkie - 27 Apr 2004

Now I really miss a description column to explain each setting. Offering help in a tooltip hardly suffices. Could the tooltip column be made visible?

-- ArthurClemens - 05 May 2004

can't we add a description column that is visible? this way I can continue to use the tooltip as a tip..

-- SvenDowideit - 06 May 2004

It would be better to have editable tables in the topic, with the EditTablePlugin, instead of using WebForm. Then you can have documentation/help with each setting/group of settings. Kind of like http://slashdot.org/my/comments/.

-- ArthurClemens - 09 May 2004

Another issue is when you want to use structured forms for both capturing and editing people's registration details. As these are also stored on the person's WikiName topic you want MultipleFormsPerPage. Furthermore you'd mostly want to hide the settings one unless the user knew they wanted to edit it, raising the requirement to hide forms.

I question that settings are better off in the topic text - I've seen users scared to edit their home topic because it had content in their that they did not understand. They thought by editing it they would probably break it. That then lessens the usefulness of the site if what it offers is for users to gain information about each other.

-- MartinCleaver - 09 May 2004

There are ways to manage complexity. The form part could be hidden/collapsed, and be opened by clicking a link.

This (ugly) example that loads a separate version of the page.

I could not find a good web examples, but they exist. Two images from my OS X file info panel:

  • Closed:

  • Opened:

Just food for thought.

-- ArthurClemens - 09 May 2004

mmmm TWikiMarkup for denoting collapsable areas would be nice for those topics with large arrays of tables - especially when you just want to get to the discussion on the bottom smile

-- SvenDowideit - 09 May 2004

Same goes for the WebForm and Attachment tables that should be collapsible and stored in a cookie/preference so the state is saved when viewing other topics.

-- ArthurClemens - 09 May 2004

http://www.devx.com/tips/Tip/13638 has a short javascript snippet which could be used to toggle the css visibility/display properties of the meta elements. I think it would also work for the hiding the much-too-visible-meta in diffs.

-- MattWilkie - 14 May 2004

I discovered a possibly unwanted side effect for using forms for the SKINS setting in user's topic: because the User Preferences are final you can't have different skins for different webs as the user's setting always wins. Workaround is to omit SKIN setting from the form.

moved draft docs to final docs in TWikiForms

-- MattWilkie - 27 Jul 2004

This depends on the setting TOPICOVERRIDESUSER in TWikiPreferences. If on, the web settings win over the user settings.

-- ArthurClemens - 27 Jul 2004

Ah, I didn't know about that setting. Thanks. It's a club when what is needed is only thumb tack though as it causes all system prefs to override all user prefs (unless the user uses FINALPREFS and names each one he wishes to attempt to control) when only a single preference is (known to be) problematic.

-- MattWilkie - 28 Jul 2004

AllowMultipleForms and MultipleFormsPerTopic as requirements drop out of UsingFormsForSettings - as I understand it this is not possible yet.

-- MartinCleaver - 12 Sep 2004

Using forms for settings has the disadvantage that you cannot mix settings with free form documentation. ThomasWeigert's PreferencesPlugin does solve this issue nicely. How about retiring this UsingFormsForSettings feature and bundle the PreferencesPlugin as one of the PreinstalledTWikiPlugins?

-- PeterThoeny - 08 May 2005

In my opinion, neither settings in text nor settings in forms is really good. As discussed in TWikiWhatWillYouBeWhenYouGrowUp, I view TWiki is a delivery vehicle for web applications. Settings define configuration options for the platform, as well as the various applications. These settings, in my opinion, belong neither in the whiteboard application (the text area usually referred to as the wiki) nor the form application (a space for editing certain meta data, typically associated with the white board). Ideally, there should be another TWikiApplication for editing settings that is not mixed into the other applications.

UsingFormsForSettings is a non-starter for sure. Just think about all the topics where settings could appear. Do you really want these settings to show up in the form and be prominently displayed with the topic? Currently most users hide topic specific settings with HTML comments, but that is really a kludge. Clearly, though, that demonstrates that users do not want to see settings in their topics.

But in the meantime, the PreferencesPlugin gives (I think) a convenient enhancement to the current text-based realization of settings. Given that it is a plugin, it is non-commital and can be switched for a better solution at a later time.

-- ThomasWeigert - 08 May 2005

As a reminder, this feature has been retired in Dakar in favor of PreferencesPlugin. Settings can be put in metadata by an editor accessible from the =More..." link.

-- ThomasWeigert - 06 Aug 2005

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng progressive_disclosure_closed.png r1 manage 13.2 K 2004-05-09 - 23:07 ArthurClemens  
PNGpng progressive_disclosure_open.png r1 manage 24.3 K 2004-05-09 - 23:08 ArthurClemens  
GIFgif twikisetingsstrcutre.gif r1 manage 24.7 K 2003-01-01 - 03:14 AntonAylward Structure of settings in Twiki - doesn't show type
Edit | Attach | Watch | Print version | History: r65 < r64 < r63 < r62 < r61 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r65 - 2005-08-06 - ThomasWeigert
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.