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. --JohnVOkay 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... ;-)
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.
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(); }
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