Change the topic context on the fly

At the moment once you have started up, you are stuck in a single topic context. To change that context - e.g. for rendering - you have to jump through hoops, calling many internal APIs. You can do this by creating a new TWiki object, but the excise is very high. The core should provide an API to allow an extension to temporarily change the topic content without having to create a new TWiki object. It would be the callers duty to revert the topic to the original setting ($oldweb, $oldtopic) once the required function was complete. Required by: PublishContrib, MailerContrib, PublishWebPlugin and anything else then needs to render multiple topics. The current APIs just don't do the job, because they don't reconstruct the preferences objects for the new topic.

Proposed API:

=pod

pushTopicContext($web, $topic)

• $web - new web
• $topic - new topic

Change the TWiki context so it behaves as if it was processing $web.$topic from now on. All the preferences will be reset to those of the new topic. Note that if the new topic is not readable by the logged in user due to access control considerations, there will not be an exception. It is the duty of the caller to check access permissions before changing the topic.

It is the duty of the caller to restore the original context by calling popTopicContext.

=cut

=pod

popTopicContext()

Returns the TWiki context to the state it was in before the pushTopicContext was called.

=cut

Proposed for 4.2 (there isn't a menu item for that release in the form)

-- Contributors: CrawfordCurrie - 03 Mar 2007

Discussion

What are the most expensive steps of creating a new TWiki object? Can they be saved using the API you propose?

-- MichaelDaum - 04 Mar 2007

If the TWiki object was reusable in a reliable way this would have a much higher potential to speed up TWiki.

-- MichaelDaum - 04 Mar 2007

This would also be a useful enhancement for the PublishWebPlugin when re-publishing all topics.

Suggestion: Use more descriptive funtion names than pushTopic / popTopic. The word pushTopic could mean many things, such as pushing topic text to somewhere else (like in a CMS.) How about pushTopicContext / popTopicContext?

-- PeterThoeny - 05 Mar 2007

The most expensive part of making a new TWiki object are (1) preferences and (2) object creation (new calls). The TWiki object is reusable, in the sense that the functions I describe above are implemented, and work. pushTopicContext is fine by me.

-- CrawfordCurrie - 05 Mar 2007

Does it recreate the preferences as "seen" from the given topic, reading the topic preferences, reading the web preferences? Does it reinitialize the plugins afterwards? There are some variables in the TWiki object itself that depend on the requested topic. Just recently some new variables (requestedWebName) sneaked in. They might need appropriate maintenance. Note sure.

-- MichaelDaum - 05 Mar 2007

Does it recreate the preferences as "seen" from the given topic - yes. Does it reinitialize the plugins afterwards - no. That's a thorny topic, and I don't think it will ever be done properly until the plugins architecture is fixed. Thanks for highlighting requestedWebName - I wasn't aware of this hack. I think it should be left at it's original value, though; after all, it is intended (I think) to record the originally requested web name irrespective of subsequent hacking of the web.

-- CrawfordCurrie - 06 Mar 2007

Perhaps there should be an additional flag or getter function in the twiki object that lets you know if the context has been mucked with since the request was intially processed? And a getter that returns a secondary object reference with a shallow copy of the twiki object saved by the first pushTopicContext. That way if some code paths care about original request details perhaps they could get a handle to the object at the top of the stack? Or to know to return N/A when asking to evaluate some property of a page with dynamic context that doesn't make any sense to ask about.

-- NeilRG - 13 Mar 2007

Hmmmm. The code I have at the moment basically just pushes the context onto a stack. "The context" is defined as: the prefs, and selected settings in the twiki singleton. The stack is maintained in the singleton itself; there is no new twiki object pushed. So if, say, the "old topic" defined a preference, the "new topic" context still has that preference. This is basically the way include works, and the simplest way I could get topic contexts to work. Otherwise managing the prefs (especially restoring what went before) gets to be quite horrendous.

There are already a couple of vars - "BASETOPIC" for example - that give you the base context of the request. And I wasn't thinking of rewriting the URL or anthing, so $query still tells you where the request started.

-- CrawfordCurrie - 13 Mar 2007

Tracked in Bugs:Item3781

CC

This once was accepted by general consensus. Spec was discussed and agreed. Customer advocates missed that the discussion was over.

In twiki app I must remember to have a field value so people can flag it as ready for release meeting. Then the customer advocate can decide if consensus is already reached so that no meeting decision with vote is needed (ie all agrees and no concerns open).

CrawfordCurrie rightfully implemented the feature. Good

-- KennethLavrsen - 09 Apr 2007

I fixed the function names in spec as implemented.

-- PeterThoeny - 08 May 2007