Simple Examples?
Stephen
around the various options for presenting graphs to the user (webdot
etc) and this seems to be the most modern in approach (JS-client+PHP-
server) and in keeping with the direction of web technology in
general.
Anyway, I've been experimenting for the last couple days with getting
this running and I'd appreciate some help! The most important issue
for me is that I'd like a simpler example than the one given. I have
been trying to reverse engineer the project to create the simplest
case, which for me would be
mydomain.com/displaygraph.php?filename=parseddotfile.xdot
Would it be possible to see how something like this would work, or
even how to "feed" a fresh parse (as a string) directly into the
client's Canviz? Thanks for any guidance.
I also thought I'd share some errors that I get when I use the
included example:
- Safari and Firefox do not accept vanilla loads of the example
index.html. The page loads, and the UI shows, but the fields remain
empty. Inspecting the web console reveals several errors:
- ReferenceError: Can't find variable: Ajax
- Value undefined (result of expression graphs.sort(function (a, b)
{
a = a.replace(/.*\//, "").toLowerCase();
b = b.replace(/.*\//, "").toLowerCase();
return a > b ? 1 : a < b ? -1 : 0;
}).each) is not object.
- Function $ undefined (or something to this effect, I fixed it (at
least, the error log if not the actual error) by adding the following
function to index.html)
function $() {
var elements = new Array();
for (var i = 0; i < arguments.length; i++) {
var element = arguments[i];
if (typeof element == 'string')
element = document.getElementById(element);
if (arguments.length == 1)
return element;
elements.push(element);
}
return elements;
}
- Similar errors for $H and $F
Anyway, I just thought that you'd like to know that this error/
beginner's error is creeping up in at least one case.
Another question I have is whether this is frame-compliant or the code
always reaches up to the top-level browser frame. The answer will be
apparent once I get this working but a little reassurance never
hurt ;)
Thanks for all that you're doing to create this!
Stephen
Ryan Schmidt
> Hi, I really like where this project is going. I've been shopping
> around the various options for presenting graphs to the user (webdot
> etc) and this seems to be the most modern in approach (JS-client+PHP-
> server) and in keeping with the direction of web technology in
> general.
Thanks! I certainly hope to make Canviz the coolest way to display
graphs on a web page.
> Anyway, I've been experimenting for the last couple days with getting
> this running and I'd appreciate some help! The most important issue
> for me is that I'd like a simpler example than the one given. I have
> been trying to reverse engineer the project to create the simplest
> case, which for me would be
>
> mydomain.com/displaygraph.php?filename=parseddotfile.xdot
>
> Would it be possible to see how something like this would work, or
> even how to "feed" a fresh parse (as a string) directly into the
> client's Canviz? Thanks for any guidance.
All you need is to put a canvas called "graph_canvas" on your page
and then write this JavaScript:
canvas = $('graph_canvas');
if (canvas.getContext) {
var ctx = canvas.getContext('2d');
graph = new Graph(ctx);
graph.load('mydomain.com/displaygraph.php?
filename=parseddotfile.xdot');
}
All of this is part of Prototype, so you need to include prototype.js
before you include canviz.js, like the example index.html does. And
you also need to include path.js, after prototype.js but before
canviz.js.
> Anyway, I just thought that you'd like to know that this error/
> beginner's error is creeping up in at least one case.
>
> Another question I have is whether this is frame-compliant or the code
> always reaches up to the top-level browser frame. The answer will be
> apparent once I get this working but a little reassurance never
> hurt ;)
Canviz doesn't do anything frame-related, so I don't see a reason why
it wouldn't work. I haven't tried it though. Let me know what happens.
> Thanks for all that you're doing to create this!
Thanks for your message! And let me know of any other problems you
encounter. And keep an eye on the issue tracker for the open issues
I'm aware of:
Stephen
- This works fine in frames
- The example package doesn't have prototype.js and ajax.js in the
right folder, and once I moved them there (as is kind of implied in
the html headers in index.html) all the errors I listed above
disappeared
- The dynamic loading is possible also using javascript calls.
Speaking of...
I haven't figured out svn yet, but let me suggest a minor change which
I think is a valuable improvement:
in canviz.js, after the line
parse: function(response) {
insert
var graph_src = response.responseText;
if (graph_src) {
this.parseFormat(graph_src);
}
},
parseFormat: function(graph_src) {
and then remove
var graph_src = response.responseText;
from where it originally occurred (like 5 lines later). This will
allow for a remote caller to use 2 options (right now only the first
is possible):
graph.load(url)
graph.parseFormat(rawGraphFormat)
This means, in my case, that I can generate a dot format and not have
to write it to disk in order to pass it to the user's browser.
Ryan Schmidt
> HI! I have learned much in the last 12 hours:
> - This works fine in frames
> - The example package doesn't have prototype.js and ajax.js in the
> right folder, and once I moved them there (as is kind of implied in
> the html headers in index.html) all the errors I listed above
> disappeared
There is no ajax.js; AJAX functions are provided by prototype.js. But
as far as I can tell, everything is already in exactly the right
place. I mean, I've been developing and using this for two years and
it always works for me. The directory structure I provide is as follows:
<root>/
canviz.js
index.html
path/
path.js
prototype/
prototype.js
And index.html has these lines:
<script type="text/javascript" src="prototype/prototype.js"></script>
<script type="text/javascript" src="path/path.js"></script>
<script type="text/javascript" src="canviz.js"></script>
So everything works. You're free to put the JavaScript files in
different directories and adjust the script tags to match, of course.
> - The dynamic loading is possible also using javascript calls.
> Speaking of...
>
> I haven't figured out svn yet
How did you get the source code if not using "svn checkout"?
> but let me suggest a minor change which
> I think is a valuable improvement:
>
> in canviz.js, after the line
>
> parse: function(response) {
>
> insert
>
> var graph_src = response.responseText;
> if (graph_src) {
> this.parseFormat(graph_src);
> }
> },
> parseFormat: function(graph_src) {
>
> and then remove
>
> var graph_src = response.responseText;
>
> from where it originally occurred (like 5 lines later).
It's much clearer if you provide standard unified diffs to express
your changes. To make a unified diff, you would check out the source
from the repository, make changes as desired, then run "svn diff" and
send the output of that command.
> This will
> allow for a remote caller to use 2 options (right now only the first
> is possible):
> graph.load(url)
> graph.parseFormat(rawGraphFormat)
>
> This means, in my case, that I can generate a dot format and not have
> to write it to disk in order to pass it to the user's browser.
You don't have to save the dot file to disk if you don't want to;
that's entirely up to you at the server side. But you do need to run
it through Graphviz to convert dot format to xdot format (which adds
the _*draw_ attributes that Canviz uses to draw the graph). So the
only advantage I could see to offering a parseFormat() method as you
suggest is if you wanted to provide your own AJAX mechanism to
transport the xdot-format file from the server to the client. Is that
what you want to do? If so, is there something unsatisfactory about
Prototype's AJAX transport which Canviz uses?
Stephen
> canviz.js
> index.html
> path/
> path.js
> prototype/
> prototype.js
>
root
canviz
path
branches
tags
trunk
vendor
excanvas
prototype
wiki
etc etc... this is why I had to move the files. I guess what I meant
was that I hadn't figured SVN out enough to submit diffs, though I
have been able to checkout the package as above. Anyway it's clearly
beginner's confusion on my part, but I've fixed it...
> You don't have to save the dot file to disk if you don't want to;
> that's entirely up to you at the server side. But you do need to run
> it through Graphviz to convert dot format to xdot format (which adds
> the _*draw_ attributes that Canviz uses to draw the graph). So the
> only advantage I could see to offering a parseFormat() method as you
> suggest is if you wanted to provide your own AJAX mechanism to
> transport the xdot-format file from the server to the client. Is that
> what you want to do? If so, is there something unsatisfactory about
> Prototype's AJAX transport which Canviz uses?
Based off of only the example index.html, the means for a canviz
instance to render a xdot file is by loading the url of the file. I
am seeking a means of sending off data that's been generated in a php
script (and passed through server-side graphviz) without sending a
file url. The diff above works (I'm using it now), but I would
definitely be open to the "official" method. What is it? Right now
I'm doing something like:
canvizFrame.load_graph(xdotString);
for my ajaxy goodness.
Stephen
function load_graph(dotFormat) {
if (canvas.getContext) {
graph.parseFormat(dotFormat);
}
}
to complete the circle
Ryan Schmidt
>> <root>/
>> canviz.js
>> index.html
>> path/
>> path.js
>> prototype/
>> prototype.js
>
> Here's my directory structure:
> root
> canviz
> path
> branches
> tags
> trunk
> vendor
> excanvas
> prototype
> wiki
> etc etc... this is why I had to move the files. I guess what I meant
> was that I hadn't figured SVN out enough to submit diffs, though I
> have been able to checkout the package as above. Anyway it's clearly
> beginner's confusion on my part, but I've fixed it...
Ah, sounds like you checked out the entire Canviz repository. You
really only need the trunk folder inside the canviz folder. You can
trash everything else.
See also the HowToUse wiki page:
http://code.google.com/p/canviz/wiki/HowToUse
>> You don't have to save the dot file to disk if you don't want to;
>> that's entirely up to you at the server side. But you do need to run
>> it through Graphviz to convert dot format to xdot format (which adds
>> the _*draw_ attributes that Canviz uses to draw the graph). So the
>> only advantage I could see to offering a parseFormat() method as you
>> suggest is if you wanted to provide your own AJAX mechanism to
>> transport the xdot-format file from the server to the client. Is that
>> what you want to do? If so, is there something unsatisfactory about
>> Prototype's AJAX transport which Canviz uses?
>
> I guess it's the Prototype AJAX transport that I'm unfamiliar with.
> Based off of only the example index.html, the means for a canviz
> instance to render a xdot file is by loading the url of the file. I
> am seeking a means of sending off data that's been generated in a php
> script (and passed through server-side graphviz) without sending a
> file url. The diff above works (I'm using it now), but I would
> definitely be open to the "official" method. What is it?
Simply pass graph.load() the URL to your PHP script that generates
the xdot file.
graph.load('xdot.php?foo=bar&whatever');
I'll add some more examples which will do dynamic graph generation,
since that's probably what most people will want to use Canviz for.
> Right now I'm doing something like:
>
> canvizFrame.load_graph(xdotString);
>
> for my ajaxy goodness.
Does this mean you are using PHP to dynamically generate the HTML and
JavaScript, using something like this?
<?php
echo 'canvizFrame.load_graph(' . js_encode($xdotString) . ');';
?>
If so, that's interesting, but I had envisioned your JavaScript being
a normal static .js file. Then from there you can call graph.load()
with the URL of your dynamic graph generator. That way you're only
dynamically generating the part that needs to be dynamically
generated -- the graph -- and the parts that don't change, the HTML
and the JavaScript, can stay in static files that can get cached by
the browser and proxies.
Ryan Schmidt
> let me suggest a minor change which I think is a valuable improvement:
>
> in canviz.js, after the line
>
> parse: function(response) {
>
> insert
>
> var graph_src = response.responseText;
> if (graph_src) {
> this.parseFormat(graph_src);
> }
> },
> parseFormat: function(graph_src) {
>
> and then remove
>
> var graph_src = response.responseText;
>
> from where it originally occurred (like 5 lines later). This will
> allow for a remote caller to use 2 options (right now only the first
> is possible):
> graph.load(url)
> graph.parseFormat(rawGraphFormat)
>
> This means, in my case, that I can generate a dot format and not have
> to write it to disk in order to pass it to the user's browser.
Although, as we discussed earlier, I don't think you'll need to use
this directly, I changed the graph.parse() function to now take the
xdot source as its argument, not the response object. The code seems
cleaner this way.
http://code.google.com/p/canviz/source/detail?r=141