The ReferenceManager currently collects inbound and outbound links, but it doesn't do anything with plugin links (i.e. [{...}]). It would be helpful, when coding cooperating plugin tags, to be able to iterate over the list of plugins defined on a page, so that a plugin at the top of a page could easily determine what other plugins are already present. For example: consider a plugin that can be used several times in a page as a marker; the first instance could scan for other instances and add them to a single output display item; subsequent instances need not display anything.

A number of intermediate steps would help, and maybe even render the idea moot:

1. The existing parser generates a DOM tree containing "PluginContent" objects, but these objects are opaque -- all the public methods of PluginContent execute the plugin. Exposing plugin class and content without executing it would help, and we could use the existing parser to retrieve the list.
2. The page of interest (usually, but not always, the "current page") may already have been parsed, but the DOM tree of the page is inaccessible, so it has to be re-parsed. Making the parsed form of the page accessible somewhere would make this enhancement less needful; one could always just ask the engine or one of the managers for the WikiDocument, and search it. (Q: should the PluginContent have a toString method that doesn't execute the plugin?)

--Jerry Andrews, 02-Jun-2007

D'oh, you're right. The CVS trunk actually has methods like getPluginName() and getParameter(), which make the PluginContent more accessible. Backporting these methods to your 2.4. should of course be a breeze.

--JanneJalkanen, 02-Jun-2007