The foswiki svn repository will become read-only on Friday 8/8. Developers should register for a http://github.com/ account for commit access to foswiki.

Item9562: Update documentation to clarify Foswiki::Func::pushTopicContext() does not clear set variables

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Normal Closed Engine Preferences  
If a topic is missing settings for a variable, then setting from the prior topic context will still be used.

Topic 1
   * Set BLAH = TEST

Topic 2
 [No set statements]

pushTopicContext from Topic1 to Topic2 will leave BLAH set to Test. The variable should not exist when in Topic 2 context.

-- GeorgeClark - 27 Aug 2010

Gilmar, Any thoughts? Given this is a stack that normally inherits from other levels, I suspect that this might be correct, although unexpected behavior. Func documentation states: Change the Foswiki context so it behaves as if it was processing $web.$topic from now on. So I interpreted this as it replaces the Topic in the stack, although it appears to behave as if it added the topic onto the stack.

-- GeorgeClark - 29 Aug 2010

Hi George!

I didn't receive a mail notification about this item.. maybe cause "Foswiki:" prefix inhibit the notification. I was reading IRC logs today and then I came here wink

Well, the behavior you described is exactly how preferences works (it works this way now and it always worked like this): preferences are a stack (I don't remember if the exact order is this, but it's documented somewhere):
  1. DefaultPreferences
  2. Plugins
  3. SitePreferences
  4. User preferences
  5. Web
  6. Topic

The preferences stack is built at initialization time (Foswiki::new), but it changes during the request processing (especially when processing INCLUDE).

It seems to me that what you want/need is to get/check a preference of a topic, no matter what the context is. If so, you should use Foswiki::Meta::getPreference(), instead of Foswiki::Prefs::getPreference(). The former refers to preferences of the object and the second to global preferences stack.

If you're already using Foswiki::Meta::getPreference(), then we probably have a bug.

-- GilmarSantosJr

Hi Gilmar, I'll update the docs then for pushTopicContext. The statement "Change the Foswiki context so it behaves as if it was processing $web.$topic from now on." to me would imply that the topic is replaced on the stack (even though it does say push.) I was not using the Foswiki::Meta::getPreference(). I was using the pushTopicContext followed by Foswiki::Prefs::getPreference(). The difference is pretty subtle, because anything defined in the pushed topic is picked up - it's only when it's undefined in the pushed topic does the stack inheritance become clear.

I'll "fix" this with some documentation changes. Thanks.

-- GeorgeClark - 31 Aug 2010

Stack inheritance takes place if the preference is not defined at the top level topic or if it was finalized at some earlier level wink

-- GilmarSantosJr - 01 Sep 2010
 

ItemTemplate edit

Summary Update documentation to clarify Foswiki::Func::pushTopicContext() does not clear set variables
ReportedBy GeorgeClark
Codebase trunk
SVN Range
AppliesTo Engine
Component Preferences
Priority Normal
CurrentState Closed
WaitingFor
Checkins Foswikirev:8838 Foswikirev:8839
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r10 - 04 Oct 2010, KennethLavrsen
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License