TODO: #

TranscludePlugin uses a caching mechanism, we need some sort of reaper on it eventually. Not a big problem as there are not that many transclusions. Also self-referring plugins would be BAD! Hmm is this a problem with InsertPage too? --JohnV

Enhancements#

Since transcluded pages are probably from "some other" webserver they might not always be available. We already cache the page data so we cause excessive network traffic in "high-view" scenarios. Could the caching for load-reduction that is done be expanded in scope? What if the in-memory cached data was written to a persistant-cache on disk? Then when a request is recieved for a transclusion and the "other" webserver is not available we could provide the data from the persistant-cache (adding a banner disclaiming that it is from a possibly outdated cache). Thoughts? Does anyone out there make use of the TranscludePlugin? Would this be useful? What else could be done with it? --JohnV

A thought just occured, we could use the persistant-cache as a local versioning of the external page. We would then enhance the TranscludePlugin to allow "pinning" of the transclusion to a specific version. (Maybe using dates and/or traditional version numbers?) A banner indicating that the transclusion is "pinned" and a link offer to show the current version, or a diff between the pinned and current versons would of course be needed. --JohnV

Yet another thought, enable the "pinning" feature, then transculde your own wiki's pages, you could then write pages talking about how another page in your wiki has grown and evolved over time. --JohnV


Reformat Feature#

I use Transclude primarily to compose big pages out of smaller pages, so that information is accessible both ways. What would excellent is a way to reformat the inncluded text so it can fit better within a larger document.

Transforms that come to mind are:

  • scaling headers
  • removing page footers and headers
  • removing line breaks

For example, in a standalone page I may use !!! for top level headers. If that document is included in a larger document that already uses !!! then all the content appears at the same level, which is not what I want. And as content may be used in many different ways it's not possible to have a policy that always works.

Many pages have a common footer that I don't want included when combining pages.

Aside
Okay, a couple of things. It sounds like you're using the old TransclusionPlugin as it was created before the advent of InsertPage (since this plugin isn't yet available). That version of the plugin will not be updated. All new McKessonApsWikiPlugins will be 2.1.89+ based. Under 2.1.89+ the InsertPage plugin should be used for same-wiki insertions. The new TranscludePlugin (described here) is for foreign wiki page insertions via the WikiRPCInterface. --JohnV
Scale headers
Well I can see sortof why you might want to "scale headers" what can you do with the class and style parmeters to InsertPage? You can specify any old CSS formatting directives that way, but I'm not a CSS guru. --JohnV
Remove footers and headers
Well the closest you cna come is to use the section parameter and specify which ONE section you want to have inserted. I can see how that's maybe not adequate for everyone. I'll note over on InsertPage an idea to allow a range or comma delimited list of section numbers. --JohnV
Remove line breaks
I don't understand what you mean by this at all. You mean four-dash-divider based horizontal rules? No idea how this could be done. --JohnV


Has the TranscludePlugin been updaterd to work with 2.4.102? I am having trouble getting it to work on our JSPWiki (Ten3) Here is the plugin as I wrote it: [{TranscludePlugin page='JSPWiki:JSPWikiPlugins'}]. I appreciate your help!

--Bill Robfogel, 27-Apr-2007

You should use the version from the CeryleWikiPlugins distro for JSPWiki 2.4.x and newer. I'm not sure if the old one would work or not. --JohnV 1-May-2007


Update on Bill Robfogel's problem--using JSPWiki 2.4.102, and using the latest (20070216) versions of the Ceryle plugins, if we include "org.ceryle.wiki.plugin" on the search path, we get plugin insertion failed. But if we use "org.ceryle.wiki.plugin.transclude" in the search path, it finds the plugin.

When the plugin insertion fails, nothing gets logged in the wiki's log file.

I'm not sure whether "org.ceryle.wiki.plugin" is supposed to imply that the wiki should also search in (for example) "org.ceryle.wiki.plugin.transclude" or not. If it's supposed to imply searching "subdirectories" as well, I'm not sure who implements that, and to whom to report the "bug".

But if the searchPath does not imply searching subdirectories, then there's a mismatch between what the Ceryle wiki pages suggest should be done to the searchPath, and what's really needed, because the TranscludePlugin class is in the transclude subdirectory of org.ceryle.wiki.plugin.

--Steve Dahl, 16-May-2007

Hi Steve, sorry if there's any confusion on this one. Basically, the actual plugin class is org.ceryle.wiki.plugin.transclude.TranscludePlugin, but for most of the CeryleWikiPlugins I've also made a small subclass — literally only a few lines long — called org.ceryle.wiki.plugin.Transclude that just calls TranscludePlugin (and also permits people to take "Plugin" off the name), and put that calling class in the directory/package common to all the plugins so that people only need to add one path. You should only need to add "org.ceryle.wiki.plugin" unless I've somehow forgotten to add the calling class in the jar file distro, but I just checked the jar file distribution and it seems to be there.

   org/ceryle/wiki/plugin/Alias.class
   org/ceryle/wiki/plugin/alias/AliasPlugin.class
   org/ceryle/wiki/plugin/Query.class
   org/ceryle/wiki/plugin/query/QueryPlugin.class
   org/ceryle/wiki/plugin/Transclude.class
   org/ceryle/wiki/plugin/transclude/TranscludePlugin.class
   etc.
This permits me to keep all the files for a given plugin together in one directory (for those plugins that have multiple files), rename the calling classes without "plugin", as well as have a single common path for all of them. Hope this clears things up.

-- MurrayAltheim, 17-May-2007


This sounds fine to me, but most or all of the documentation I can find--for example, the TranscludePlugin page on the JSPWiki wiki--only talks about the class TranscludePlugin, not Transclude. But it also says that the searchPath is org.ceryle.wiki.plugin. And that class isn't visible in that package.

It seems to me (just a suggestion) that either the documentation should be updated to talk only about "Transclude" and not "TranscludePlugin", or else there should be a class TranscludePlugin in org.ceryle.wiki.plugin that is a clone of the Transclude class--it just forwards all requests to the real plugin. Of course, I can see that having two classes in different packages but the same name might be awkward in some circumstances, so I'm not stuck on that approach.

Thanks for the clarification.

--Steve Dahl, 17-May-2007

Steve, the thing is that there's an historical issue here. TranscludePlugin used to be one of the JSPWiki contributed plugins, written by John Volkar as part of the McKessonApsWikiPlugins. John stopped maintaining those plugins (and there were questions over IP, etc.) so he donated them to me to maintain. I don't have time to keep both sets of pages up to date, and I don't feel it's my place to modify the JSPWiki site insofar as doing anything other than stating the actual situation, i.e., I effectively now have a different set of plugins that just happen to have many of the same names as John's plugins but I don't feel I can claim that mine are a replacement. That their package designation has changed makes sense in this context. The real plugin is either the full path to TranscludePlugin that includes .transclude. or the one to Tranclude that doesn't. It really depends on how one installs the plugin, either as a single class or as part of the larger CeryleWikiPlugin distribution. In the latter case, Transclude is simply a convenience class that permits a single path designation in JSPWiki.properties rather than a whole bunch of them.

But yes, the documentation could stand some updating. Anyone who wants to volunteer is quite welcome to do so. :-)

-- MurrayAltheim, 18-May-2007

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-14) was last changed on 18-May-2007 07:26 by MurrayAltheim