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|http://www.snipsnap.org/space/SnipGraph/UML+Example] 
* UML sequence diagrams like the ones supported by [SEQUENCE|http://www.zanthan.com/itymbi/archives/cat_sequence.html]
* Statistical and Busindess charts and graphs (see [Cewolf|http://cewolf.sourceforge.net/new/index.html] and [JFreeChart|http://www.jfree.org/jfreechart/]).
* Other data visualizers like [prefuse|http://prefuse.sourceforge.net/]

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