Item9562: Update documentation to clarify
Foswiki::Func::pushTopicContext() does not clear set variables
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
If a topic is missing settings for a variable, then setting from the prior topic context will still be used.
* Set BLAH = TEST
[No set statements]
pushTopicContext from Topic1 to Topic2 will leave BLAH set to Test. The variable should not exist when in Topic 2 context.
- 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.
- 29 Aug 2010
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
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):
- User preferences
The preferences stack is built at initialization time (
), but it changes during the request processing (especially when processing
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
, instead of
. The former refers to preferences of the object and the second to global preferences stack.
If you're already using
, then we probably have a bug.
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
. I was using the
. 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.
- 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
- 01 Sep 2010