• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Tried to use the form-based editing of existing preferences in TWikiPreferences and got:

  1. After saving, most variables are hardcoded, some make no sense afterwards (i.e. MAILTHISTOPIC will always mail TWikiPreferences topic, not the current topic)
  2. No way of retrieving original topic content (original topic was "r0", saved topic "r1"). This issue is not exclusive to this functionality or topic - it just feels more tense when you want your original settings restored - and FAST) :-) This behaviour is in SVN checkout area only.

Attaching diff of original topic content (SVN 8080) and topic content after this procedure:

  1. Visit TWiki.TWikiPreferences
  2. Click "Edit"
  3. Click "Save"

SP

You are obviously working in a SVN checkout area. In a proper installation, the version of the topic is not r0.

The PreferencesPlugin uses the preRenderingHandler, which renders the fields for edit after all variable substitutions have been performed. So it is working as per spec.

The setting of MAILTHISTOPIC looks fine to me.

If you don't like the behaviour of PreferencesPlugin in this respect, you need to raise an item against it.

CC

Being able to roll back is the most important thing - haven't tried it in a proper build, you're right about that part smile

I can accept the specs for the PreferencesPlugin, at times there's probably a very good reason to edit only after substitutions. Thanks for enlightening!

SP

Sorry, I can't accept the spec for the PreferencesPlugin. I tried it out, found it great, then I found out that it messed up all my Preferences.

For Instance, I had some custom variables using %WEB% or %TOPIC%, that was all set to TWiki and TWikiPreferences. Theres no reason for me to edit a pre-rendered value. It's always easier to edit %SCRIPUTRL{...}% than the full path, or %ICON{blah}% then the rendered html tags. Thats actually the advantage of variables!

If you decide that this is the right way this plugin should work, it is not useful for me. Should I start a discussion about this elsewhere? Plugins web?

-- StefanSteinegger

Form based editing of variables is a very userfriendly enhancement. Agreed with Stefan, it is rendered useless because variables get expanded. Examples: ATTACHEDFILELINKFORMAT and TOPICURL, EDITURL, EDITTOPIC point always to TWikiPreferences instead of current topic.

-- PTh

First - let us seperate the two issues.

  • This bug reports mainly deals with the PreferencesPlugin which I agree 100% is no good the way it works now. If this is supposed to ship with Dakar it must be fixed first. If it is just a plugin you have to download and install - then this bug should not be classified as urgent but as normal. But then the use has to be removed from the preferences topics in Dakar.
  • The issue with not being able to restore the r0 version has nothing to do with the plugin. That is an issue you also see if you edit normally. As long as the distribution (non SVN) version of TWiki contains topics that are r1 this is not a big issue. I raised a bug report on it a while ago. Bugs Item929

So let us keep this bug report focussed only on the function of the PreferencesPlugin.

KJL

There is no clear spec for the plugin except in code. I asked in TWiki:Plugins.PreferencesPluginDev for a good reason on current spec, no reply yet. But it seems we can all agree current functionality renders the plugin useless - so let's update it and make it useful again? (CC already hinted on what needs to be changed).

I agree on the urgent priority.

SP

I would say that this is urgent if we want to ship the Plugin with Dakar. If Plugin is not ready for Dakar release we should not hold up the release and ship without the PreferencesPlugin.

-- PTh

I have attached a patch changing the used handler to beforeCommonTagsHandler.

Using this handler means that * Set stuff in verbatim blocks are also soaked up by the plugin - but I don't see a big problem with this, as everything left untouched while editing is also written back untouched.

Much better than before, anyway. I guess there's a few lines of code somewhere in the engine that already handles the verbatim blocks out / verbatim blocks in that could be cut'n'pasted if somebody wants a run for perfection (with regards to the verbatim blocks :-)).

Please commit the patch if you see fit, else if there's no comments I'll do it tomorrow.

-- SP

SVN 8160 / 8170 / 8171 (8171 is a minor format change of a few settings in TWikiPreferences).

-- SP

ItemTemplate
Summary "Form-based editing of existing preferences" in TWikiPreferences expands variables (patch suggestion attached)
ReportedBy SteffenPoulsen
Codebase

SVN Range Tue, 03 Jan 2006 build 8080
AppliesTo Engine
Component PreferencesPlugin
Priority Urgent
CurrentState Closed
WaitingFor

Checkins 8087 8099 8160 8170 8171
Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff form-based-editing.diff r1 manage 11.2 K 2006-01-03 - 21:10 SteffenPoulsen Diff on formbased edit in TWikiPreferences
Unknown file formatpatch utilize_beforeCommonTagsHandler.patch r1 manage 0.7 K 2006-01-07 - 14:51 SteffenPoulsen  
Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2006-01-08 - SteffenPoulsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback