Comments welcome...

To Do list#

• This plugin should use the temp-dir defined in jspwiki.properties, not the system temp-dir.
• If there is a syntax error in the graph data provided by the user, the plugin feedback is a bit ugly, IOException, graphviz process returned non-zero exit code. doesn't tell the user that the problem is just some bad syntax in his graph data.
• The obvious extension to hybridize this with the QueryPlugin to get a graph of the links between any set of pages via a query should be considered.
• In addition to the URL and label attributes created when imap=true maybe 'tooltip's should be made for each node? Not sure what the contents should/could be...

General Comment#

Never having used graphviz in the past, this was interesting to play with, but frustrating. The basic syntax is very approachable, but fine-tuning the graph to get the output effects that you want is not something that novices are going to pickup well. In short its much easier for a person to get a good layout by hand using a drawing tool, than it is for them to get graphviz to create one. I'm considering this diversion at a close for now; at least until I have a clear need and specific use for autogenerated graphs. --JohnV

Okay so I take it back. I did a little job at work where I wanted a dataflow diagram for an embedded micro project, but I didn't feel like creating a drawing of it using a drawing package. So... I wrote up a wiki page description of the project, and used this plugin to create the diagram, and you know what? it was reasonable. Not perfect mind you, but okay enough for the 2 minutes it took to type in the node1->node2 style data. I'm trying to think if there are ways to make the output prettier without adding user labor, make have the plugin generate a standard preamble to the graph, I found that there are afew settings that neato will almost always work better with. --JohnV

---

Generalized Image Producer framework#

Hi John. First of all, thanks for making this great plugin available! The integration with GraphViz is great, but I also like the idea of using the attachment mechanism as a local cache for the image.

I wonder if it could be refactored into a generic framework for tools that can take a text input and generate an image representation of it. Examples that come to mind:

• SVG with Batik (already covered in a similar way by SvgChartPlugin)
• Mathematical equations (already covered by MathPlugin)
• UML class diagrams like the ones supported by SnipSnap
• UML sequence diagrams like the ones supported by SEQUENCE
• Statistical and Busindess charts and graphs (see Cewolf and JFreeChart).
• Other data visualizers like prefuse

All those tools could have their own plugins, but that would imply in a lot of duplicated code...

So the "Image Producer Plugin" could work like this:

• take as an argument a class name of an adapter class, that would implement a contract interface;
• capture the remaining plugin arguments in a name-value pair list;
• check the attachements and .dat file to verify if a new image is needed; if yes, then:
• pass the arguments plus the plugin text body to the adapter instance;
• invoke the contract method in the adapter that would call the XYZ tool to generate the corresponding image file;
• generate the attachment files;
• generate the img statement.

Another option would be to add this framework to the JSPWiki core, creating a specialized form of the plugin mechanism that would incorporate the mechanism described above, and take a slightly different form of the default contract interface, say com.ecyrd.jspwiki.plugin.WikiImagePlugin.

Sorry for the long rambling. I will try my hand at integrating some of the tools I described above, but I hate to think that I will be duplicating a lot of your code... ;-)

-- NascifAbousalhNeto

On another thought, it might be easier to just encapsulate the picture and image-map files attachment management in an abstract class, and use a concrete subclass to implement just the GraphViz wrapper. Then other image generators could implement just their own subclass implementations.

-- NascifAbousalhNeto

---

I found a problem with the current image generation decision process; it does not work properly if the wiki is using the FileSystemProvider. In this case context.getPage().getVersion()) will always return -1, and that seems to break the program logic.

One solution is to add the following check to the very beginning of the execute method. I tried to check on the provider name but it is "hidden" under the CachedProvider. It doesn't solve the problem for this provider, but at least provides a clear explanation to the user of what is wrong.

        if (context.getPage().getVersion() == WikiPageProvider.LATEST_VERSION) {
          reportProblem("This plugin requires a versioned page provider");
          return problemReport();
        }

-- NascifAbousalhNeto

---

One of my dot files looks totally different rendered on the command line or using the plugin, despite imap=false (it also takes much longer). How can I have a look at what is actually passed to the graphviz binary? -- Tobias Weber

Open the attached .dat file with a text editor, it contains the raw data passed to the binary. --JohnV