Tags:
create new tag
, view all tags

Bug: Some plugins need to know about includes

As described elsewhere e.g. IncludedTopicVariableNeeded, some plugins e.g. TWikiDrawPlugin can't deal with include topics.

Test case

  • Create a topic e.g. TestDrawing, put in %DRAWING%
  • Click on drawing and put something in it
  • Create a topic e.g. TestInclude, that includes previous one e.g. %INCLUDE{"TestDrawing"}%
  • The image will not appear
  • e.g. see Sandbox.TestInclude and Sandbox.TwikiDrawPluginPlusInclude

The problem is that the plugin doesn't know the actual topic that contained the drawing. If the TWikiVariables used to envoke the plugin includes %TOPIC% it can find the topic, but seems over the topic to ask the user to type something the system should be able to work out by itself.

One fix might be to have another plugin call that is invoked inside handleIncludeFile rather than in handleCommonTagsCore. Another would be allow the text in the topic to be modified by a plugin before the call the handleCommonTags is made. This would allow entries such as topic=%TOPIC% to be added. The second option is a bit too messy for my liking.

Environment

TWiki version: 01 Dec 2001, current Alpha
TWiki plugins: TWikiDrawPlugin and others
Server OS: N/A
Web server: N/A
Perl version: N/A
Client OS: N/A
Web Browser: N/A

-- JohnTalintyre - 26 Apr 2002

Follow up

This needs to be fixed in the system. There is a bug somewhere because TWiki::handleIncludeFile does already expand internal tags like %TOPIC%, %ATTACHURL% with the web and topic name of the included topic.

-- PeterThoeny - 26 Apr 2002

I can't quite see how this can happen as the context of the call to the plugin, i.e. commonTagsHandler is not the context of the topic that, for example, includes the drawing. So the internal tags are fine but not set to what we want after a call to the plugin handler commonTagHandler.

-- JohnTalintyre - 15 May 2002 -- JohnTalintyre - 26 Apr 2002

Anyone else got some thoughts on this? It's a bit annoying as it means a book made up by include many other topics loses all the drawing done using TWikiDrawPlugin.

-- JohnTalintyre - 15 May 2002

I changed a line in handleIncludeFile in TWiki.pm line 959 from

     handleInternalTags( $text, $theTopic, $theWeb );
to
     $text = handleCommonTags( $text, $theTopic, $theWeb, @theProcessedTopics );

That seemed to work with a case similar to Sandbox.TwikiDrawPluginPlusInclude on my installation which is the 2001-12-01 release, plus this fix. Not fluent in the internals of TWiki yet, I'm not sure it doesnt' break anything else, i.e. I have only tested it with the TWikiDrawPlugin where expansion of ATTACHURL was the problem. The fix does not allow you to edit the drawings from the "main" page which isn't a problem for me as the page itself cannot be edited from there. It would be nice to disable editing though.

-- RobinRosenberg - 30 May 2002

Fix record

Here is the sequence of handling the common TWiki tags: (pseudo-code)

  • handleCommonTags:
    • handlePreferencesTags
    • handleInternalTags
    • handleIncludeFile:
      • handlePlugins
      • handleInternalTags
      • handleIncludeFile recursively
    • handlePlugins
    • handlePreferencesTags
    • handleInternalTags
    • handleToc

The red part is added. The plugins have now the chance to handle the tags with the correct topic and web.

This will fix the problem of included topics that have plugin handling which depends on the topic and web. The TWikiDrawPlugin problem is almost solved. The plugin itself needs to be made aware of the topic and web, see comments in TWikiDrawPluginDev.

But there is a "gotcha": Plugins that depend on handling a complete topic do not work correctly anymore. For example, at work we have this setup:

  • A topic is included that contains a table which is generated dynamically (for example with a FormattedSearch)
  • A footer is added in the including page which contains some SpreadSheetPlugin formulas to calculate some statistics.

The table gets handled by the plugin in two steps, confusing the statistics.

The solution is a new isIncluded parameter which gets passed to the Plugin's commonTagsHandler function. Now it is under the control of the Plugin if to handle the tags in an included topic or not.

Changes to TWiki.pm in latest Alpha:

1064,1067c1064
<
---
>
>     # Wiki Plugin Hook (4th parameter tells plugin that its called from an include)
>     &TWiki::Plugins::commonTagsHandler( $text, $theTopic, $theWeb, 1 );
>
1605c1602
<     &TWiki::Plugins::commonTagsHandler( $text, $theTopic, $theWeb );
---
>     &TWiki::Plugins::commonTagsHandler( $text, $theTopic, $theWeb, 0 );

A plugin can now decide with this code to bail out in case it is called from an included topic:

sub commonTagsHandler
{
### my ( $text, $topic, $web, $isIncluded ) = @_;
# do not uncomment, use $_[0], $_[1]... instead

    if( $_[3] ) {
        # bail out, handler called from an %INCLUDE{}%
        return;
    }

    # do normal processing...
}

In TWikiAlphaRelease and TWiki.org.

-- PeterThoeny - 07 Jun 2002

Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r9 - 2002-06-07 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.