| Project: | Graphviz Filter |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
This is not exactly a for-release patch, but I want to throw it into the ring for feedback.
Option 1 (easy) I wanted to add a button for directly downloading the .dot file created. In my case for re-importing into a further graphic graph program (Omnigraffle) to get more visual control later.
That was cool.
Option 2 (fun) I added support to graph PANELS.module structure. This I've done, and is working lovely for me. I've also started on a rough 'Views' diagram also, but that deserves its own graphviz sub-module.
HERE I'll attach the output I've got so far. It's helping my internal documentation already.
For comparison, this is the sort of result I was building by hand before I decided a tool like this could help.
with the .dot file support I can import my Structure, then annotate it
| Attachment | Size |
|---|---|
| graphviz-panels_schema_and_dot_file.20100123.patch | 1.64 KB |
| diagram_of_interest_panels.png | 377.3 KB |
| interest-news_page-views_plus_panels.png | 294.7 KB |
Comments
#1
Thanks for the great initiative. Automatic documentation is a big part why I built Graphviz Filter!
I can't find the patch for the panels schema though - please upload it at your convenience.
#2
Must forgotten a 'new file' flag when I made the patch. My bad, posting from DrupalSouth conference. Just had Angie Byrons talk, I may have been pleasantly distracted when I rolled it!
I'll try again...!
.. yeah, I needed 'fakeadd' http://wimleers.com/blog/cvs-diff-new-files-fakeadd to add brand new files.
Here again:
#3
Is it worth moving forward with my ideas?
In the pipeline, I've got a few ideas -
* The above 'panels' schema, cleaned up a little.
* The additional 'views' schema, broken off into its own add-on, diagraming at least the individual 'displays' of a view.
Some base additions, including :
* .dot file download
* a settings page to enter the path to graphviz binary even if you are not using the 'filter' method. Currently that's hard to find if you only want schemas.
* A bit more of an API to make adding elements easier
- panels_schema_construct_item() that can dump arbitrary PHP objects
- A rendering abstraction that can set rules for which graphviz element (style and shape) to use for different objects. This helps extension AND user styling preferences
They all may sort of pile on to each other as patches, unless you are open to a bit of a rewrite. Maybe a 6.x-2-dev branch?
This is all just about the 'schemas' - not the inline filter which I'm leaving alone
#4
I'm totally open for these ideas and I appreciate the time you put in them. Furthermore, I've been wanting to bring in styling and processing enhancements to the submodules just like you mention. I havent had tme to devote to Graphviz Filter lately, that's all.
So please send in your patches. I'd rather keep everything on the current branch.
#5
Don't know how further along you are in the styling options, but here's what I was thinking to implement before you stepped in:
* Use a drupal_alter('graphviz_schema', $name, $G) to allow modules to alter a graph before it's rendered.
* Use a centralized schema settings form where each schema module specifies the number of entities being graphed. For example, in the case of the taxonomy schema, we render vocabulary and term entities. The schema form would allow styling each entity separately, and possibly the edges between them too.
#6
Actually, I did a modification to my current dev branch just recently that does allow selection of just which entities get displayed in which graph. On a site with 17 views and 17 panels the result really wasn't telling me anything useful without filtering :-)
I've not put in any drupal_alter yet. To do so we may have to keep the objects in array form a little longer than they currently are. Right now the creation of graphviz objects is basically string concatenation.
I'll tidy up what I've got and feed it back soon.
#7
The filtering option sounds useful. There's someone else working on generating a node/user relationship schema, and they were talking about styling too, so it might be a good idea to coordinate with them once you've got shareable code. Thanks!
#8
@dman, since you haven't put anything up yet, I put up mine over at #212362: Display user/node relationships for you to check out. We're working on different schemas, but we're both going to ultimately need configurable styling, so it would be good to compare what we've got, maybe come up with something that'll work for both.
#9
If you want, here's a full diff of all the things I've been doing. It's quite a branch, BUT is not touching the existing original module - much.
I've done the 'panels' and the 'views' bits in stand-alone modules, so they are independant. Then recently started to look at the 'UI' addition to provide a central graph-builder, and a non-"filter" place to set the path to the binary.
Anyway, as far as pluggable theming goes, my thoughts so far have been to using a hook that defines how different modules define how to build their respective objects.
I've also been abstracting a few build functions into more re-usable routines, but not really started on a big picture rewrite on them ... was pending feedback on activity for this module before starting a rewrite.
What I've done so far for a shared library is now "graphviz_utility.inc", eg graphviz_construct_record() which uses the rendering hint hook callback.
The styling goes like this: different types of element look different.
What they look like is defined in an overridable array of graphviz object attributes, as here
<?php/**
* Sorta hook to support styling properties when creating records
*
* Collected here for better maintainence, and to allow overrides.
* Each element being rendered may have a 'type'. depending on the type, we will
* add the following GraphViz attributes.
*
* Returns an array of attributes that we can use to style graph elements.
*/
function views_schema_graphviz_styles() {
return array(
'block' => array(
'shape' => 'box3d',
),
'view' => array(
'shape' => 'Mrecord',
),
'views' => array(
'fillcolor' => 'bisque2',
'style' => 'filled'
),
'view-block' => array(
'shape' => 'box3d',
'style' => 'filled'
),
'view-default' => array(
'style' => 'dashed'
),
'view-panel_pane' => array(
'fillcolor' => 'bisque1',
'style' => 'filled'
),
'view-page' => array(
'fillcolor' => 'bisque3',
'style' => 'filled'
),
'view-attachment' => array(
'style' => 'dotted',
),
);
}
?>
#10
The UI, such as it is - so far
produces:
#11
+ Subscribe
#12
I've finally found some time to spend on Graphviz Filter; sorry for taking so long to get back to you. And you've packed your patch with so many ideas :-)
Here are my comments:
* Download DOT file: I've added to the core module 2 arguments:
@link-inputand@link-outputto allow embedding links to the input and output files. I've also added a 'dot' output format which outputs the *processed* DOT script, i.e. with position information. Would these additions solve your original .dot file download need? Finally, I've updated the API functiongraphviz_filter_renderto accept arguments that control the graph rendering.* Graphing panels and views: fantastic stuff. I suggest to fork them in your own module once we agree to the points below.
* Graphviz UI: that's pretty neat, but I fear the entity selection page will get out of hand when all graph generators add their entities there. Also, it would allow for unrelated types to be graphed together. Is that good? I understand it's a feature for panels + views, but what if someone selected views + taxonomies? Those 2 have nothing to do together. So a) the page has to be redesigned to account for many types and entities, and b) how to view related types together? I have some thoughts but nothing concrete.
* Graphviz styles hook: pretty good idea too, but it would be even better if these settings could go into Graphviz UI.
Note that I've created a new hook
hook_graphviz_render_alterto allow 3rd party modules to intercept a graph before it's rendered: [747154]. Does this affect what we're talking about here?#13
I wanted the .dot file before rendering - in its pure semantic state. The original modification is to export the graph to another dot-rendering program where the graph can be manipulated and layed out further (as illustrated at the top of this issue). Not sure where the position information comes from, but it's probably not what I'm looking for.
Fair enough for add-ons for the other things I'm doing. They are built like that anyway. There may be something still to refine WRT hooks and API here though.
We need a UI of some description, that screenshot was just a start. If those were collapsed fieldsets it wouldn't look so mad. The page is not 'designed' in the first place yet, so anything could be done.
There's no reason why someone wouldn't want to graph just the elements they choose. If there is no relation - it doesn't hurt anything. I DO need to be able to display some disparate elements however, so that's currently a feature, not a bug.
When I started, I had the 'panels' dynamically include the required renderer for the 'view' when it was found to be needed. That was OK, but could rapidly get out of control or become recursive if extended too far. Which is why I started using checkboxes instead. It would require strange magic to get the system to recognize possible dependencies and present them as suggestions, though that would be cool.
The styles hook idea needs work. It evolved from what I wanted to do right now, possibly lacking an overall concept. Right now, it's not so much about what color it is (thought that's a visible part of it) as it is how this element is built - like a view is a complex element.
If the element types have consistent names and consistent 'build' functions, then a certain amount can be done magically. I started this in my code structure - but without a lot of reference to big-picture. Just did what seemed to work in what seemed to be a drupal-style way - eg like theme_* hooks.
Catching the render_alter hook at the end is probably a win. My current callback thing is just tacked on.
I know my patch has 3 completely different things in one. But it was only from building one thing I wanted I found these three steps were useful ways to get there.
SHould I look at the current -dev and see what still fits?
#14
>> SHould I look at the current -dev and see what still fits?
I think most of the ideas will not clash with the new version.
>> I wanted the .dot file before rendering - in its pure semantic state
The
link-inputparameter achieves this - please try it. The positions in the output are the node positions that are computed by the graphviz algorithms to generate the graph layout.I'm still thinking about the other issues. I don't want to hold you back: you can go ahead and release a new module for the panels + views schemas, just make sure you test it with the latest dev.
#15
Very nice to see the work we've been doing seperately is exactly complemantory ! :D
Because what i have been implementing is a CRUD API and AJAX GUI for editing graphviz styles! Also it includes a graph view plugin (with selectable options) and cck fields for edge and node styles. Just working on giving it some more structure so i can post as patch... Oh and finally i was able to make the CANVIZ javascript graph renderer (http://canviz.googlecode.com) to work, this cuts down on network traffic especially for huge graphs - but it somehow doesn't work properly in IE6/7, that needs to be further investigated..
Feel free to experiment with the styles UI @ http://hfopi.org/admin/build/graphviz_styles and well a demo graph view is at http://hfopi.org/topicgraph but i have yet to find out how to best expose the different settings (like 'expose filter')..