• 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.
Home - this site is powered by TWiki(R)
Bugs > Item374
TWiki webs: Main | TWiki | Sandbox   Log In or Register

Changes | Index | Search | Go

this slipped in during the major prefs rewrite

see changes in r6292.

>      my $template = $query->param( 'template' ) ||
> -      $session->{prefs}->getPreferencesValue("VIEW_TEMPLATE", undef, 1) ||
> +      $session->{prefs}->getWebPreferencesValue( 'VIEW_TEMPLATE', $webName ) ||
>          'view';

should be getPreferencesValue() again.


I agree with Michael. In addition, the special handling for certain preferences if we are dealing with preferences that should be treated special in the user topic (e.g., VIEW_TEMPLATE) needs to be reinstated, otherwise the VIEW_TEMPLATE and similar types of variables don't work any longer; some goes for access control. -- TW


No, apart from the fact that new users all have the preference set, and it results in an error because the UserView template can't be found. I removed that preference from the new user template and TWikiGuest. A user can dictate that preference if they wish, by setting VIEW_TEMPLATE as FINAL. SVN 6338

Thomas, you are opening a whole can of worms here. There are a number of internal variables that in Cairo didn't follow the published rules for lookups. These were: protections, and VIEW_TEMPLATE.

In the recent Prefs changes I had these thoughts:

  1. The rules for variable resolution were complex and confusing to me, perhaps because of the implementation. A simple, consistent set of rules is needed.
  2. Those rules have to account for subwebs and subsubwebs inheriting prefs from parent webs, and included topics existing in the context of other webs.
  3. All variables are equal; none should be any more equal than others
  4. The same code should be used for handling preferences wherever possible, otherwise syntax diversion will happen.

It seemed to me that the authors of a topic have first call on any variable. If a topic redefines EDITBOXWIDTH, it does so for a reason, and the casual user has no business overriding that.

A wider context is the container a topic is within - the web. Again, the user has no business overriding the settings for a web; they are defined that way for a reason. If you allow users to override local settings, you end up with webs that work for some users, but not for others, with little hope of debugging.

On the other hand, the user who really knows what they are doing can set a variable as FINAL and have it dictated at lower levels.

All variables are equal, so if %ALLOWTOPICCHANGE% is in a topic it should be clear to a viewer why they are not allowed to view the topic.

So I decided to go for three functions: getWebPreferencesValue, getTopicPreferencesValue, and getPreferencesValue. The first two do exactly what it says on the tin; they only look at the nominated topic or web, and are required mainly for protections.

getPreferencesValue looks up a stack of contexts, following the order:

topic - web - user - localsite - default

In the event of an include, the local preferences of the included topic get pushed, so the lookup may become:

includedtopic - includedsubweb - includedweb - topic - web - user - localsite - default

This function is used for all other preference lookups (except where compatibility requirements dictate otherwise).

In this way the authors of a web are able to control how their web is seen by users. Users are still able to express preferences, though these may be locally overridden in a web or topic (unless FINAL).

I searched, but I couldn't find any documentation that could tell me how this logic is flawed, or why VIEW_TEMPLATE should be treated any differently. it looked like a hack, and one I didn't fully comprehend until now.

Note that I didn't go all the way on (3). Internal variables (such as %SEARCH) still can't be overridden by user preferences.

NEW if you want to examine the variables se in any particular context, use %ALL_VARIABLES%

CC


Thanks for fixing. Btw you've forgotten to mention that getPreferencesValue() checks the session in between also:

topic - web - session - user - localsite - default

which is great.

MD


Thanks Michael, yes, that's correct.

You asked in mail: > To me VIEW_TEMPLATE is treated special in contrast to most other
> variable. So far I understood that all variables should be treated equal.
> What do I have to do to set a view template for a topic in my TWikiApplication?

No, it's treated no differently to other variables - now. It was treated specially before, when the lookup process was:

session - topic - user - web - default

in this case the $nouser flag on the function call was used to exclude user from that lookup to give:

session - topic - web - default

No other variable was handled this way.

To set a view template, just

<!--
   * Set VIEW_TEMPLATE = myappviewtemplate
-->
You can do this at any level. If VIEW_TEMPLATE is set FINAL it will not be overridden by any lower level (except session? maybe an inconsistency there) _ VIEW_TEMPLATE is a variable which should never be set as a user variable. It is inherently different from other variables -- TW

CC


I am reopening this so that I can do some more tests....

The problem is that for example VIEW_TEMPLATE cannot be taken as a user variable, otherwise, it would apply everywhere, rather than just the topic at which it is intended if it was set in the user topic. There could be other variables that should always apply to the topic level, and never be spread everywhere based on that they were set in the user topic.

I will check whether your setuserpreference solves this problem, but we will need some way of designating certain variables as such. Needless to say, however, that I view VIEW_TEMPLATE and other ways of customizing a topic systematically as extremely important to TWikiApplications. -- TW


I'm not completely clear on what you are trying to do here. If VIEW_TEMPLATE requires a local value in a web or topic, then surely it can be set in the web/topic? The user setting will only override it if they have set the preference FINAL in their user topic - which is a pretty clear statement that they want it to be final!

Note that the new %IF IF{ "%WIKINAME=ThomasWeigert" then="(yes, Thomas, I know it's you!)" }: Syntax error in '%WIKINAME=ThomasWeigert' at '%WIKINAME=ThomasWeigert' gives a lot more flexibility to TWikiApplications. CC


I investigated and confirm that now the VIEW_TEMPLATE mechanism is broken. -- TW

Another thing currently broken is that if you create a new user, this user will have the template meant for the user topic only applied to all topics.


Let me explain the problem (I'll use VIEW_TEMPLATE as an example, but the issue is more generic):
  • It was desired to change the appearance of the user topic to have the form on top and to have a special edit link right below the form. This way the important data (the personal detail) will be right on top.
  • This is accomplished by defining a special template to be used for the user topics only (Main/UserView)
  • Thus we set the VIEW_TEMPLATE to UserView
  • But now (after the latest change) this is chosen as a template for all topics of every user that has this preference set as the user_topic
  • Any preference that is set in the user topic will apply everywhere, even if it is meant to be a preference just for that particular topic. Access control is handled separately, albeit the settings are also in the preferences.

I think this is a generic problem, as there could be many such properties, where you want it to apply to the user topic but they get spread everywhere. Note that this is true for the WebPreferences and TWikiPreferences topic also, but there the chances are less that one needs preferences for the topic only. However, the user topic does serve double duty as a regular topic about the user and as a special topic defining user preferences. -- TW


Ah, I start to understand. You want a topic level preference in the user topic that doesn't get interpreted as a user preference when viewing other topics, yes? The same might apply where you want (say) a different skin when viewing a WebPreferences topic, but don't want that skin when viewing any other topic in the same web. Yes, this is a generic problem. It's only truly solvable with a generic mechanism; hacking around it on a case-by-case basis is just going to create a maintenance nightmare. So, what might work? How about:
  • Local SKIN =
This would define SKIN so it applied only when viewing the topic that contained the definition. I think that would be generic enough, yes? CC
Just to double check... what you are suggesting is a second way of setting a preference (LOCAL instead of SET). In that case, this variable would only apply as a topic variable, not as a global variable. This is truly a generic mechanism, but will be some work.

But let me reiterate:

  • The ability to define topic-specific templates or skins (or other topic-specific variables) is essential.
  • This mechanism works great except for three topics: the user topic, WebPreferences, and TWikiPreferences where the topic-specific settings are misinterpreted as global settings
  • We can either
    • disallow topic-specific settings for those "special" topics, or
    • come up with a mechanism to designate some preferences as special and not globally applicable

I had earlier implemented an in-between approach: only deal with user topics as these are the primary area of conflict. Use special flag that makes such variables non-global when evaluating preferences.

I might have tended to say not to worry as having special variables in the user and other preference topics is not that important. Unfortunately, somebody has already decided to give the user topic a special appearance before I implemented this. And if a user puts such variable into the user topic, a giant mess ensues (see currently in Dakar installations). -- TW


It's not much work, I think, since I reorganised Prefs. More documentation than code. CC
Hm, actually the access preferences behave similar: there are some that are global and some that are local. But things are clear as the variables are named differently. So actually we could use VIEW_TEMPLATE and VIEW_TOPIC_TEMPLATE the same way.

MD


Michael and I discussed this on IRC. We see two sensible options:

  1. Make TEMPLATE a reserved word for variables, same as ALLOW. So * Set TEMPLATETOPICVIEW = limits the scope to the topic. This reflects the scoping rules of * Set ALLOWTOPICVIEW =
    • probably sensible to reserve TEMPLATEWEBEDIT, TEMPLATETOPICPREVIEW etc.
  2. Use * Local VARIABLE =

Personally I favour the latter for three reasons:

  1. it is a more general solution
  2. it is more intuitive
  3. it is much easier to implement

CC


Hmmmm.

Approach (1) is in line with the access control scheme. Note that we probably would also have to have something for SKIN as this problem can easily surface there as well?

Approach (2) is general and can thus apply to anything in the future.

The frustrating thing is that either is a solution that really only makes a difference in three topics... -- TW


  • Local VARIABLE = SVN 6396

The value of the local %VARIABLE% is: SVN 6396 -- CC


Verified that Local works with hidden topic settings. Restored special view of user topics in SVN 6408. -- TW
Shouldn't this expand %VARIABLE%? -- TW
No. This is a form field, not the topic body. You can't set variables in a form field. CC

ItemTemplate
Summary VIEW_TEMPLATE not settable via topic variables any more
ReportedBy MichaelDaum
Codebase

AppliesTo Engine
Priority Urgent
CurrentState Closed
WaitingFor

Checkins 6338 6396 6408 6409
Edit | Attach | Watch | Print version | History: r23 < r22 < r21 < r20 < r19 | Backlinks | Raw View | Raw edit | More topic actions

This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback