Getting Started

Although it is strongly recommended you familiarise yourself with the basic concepts in the jsPlumb Toolkit before writing an app, everybody knows that developers like to get in and get something working right away, then do some research later. So, there are a few ways to jump right in with the Toolkit.

A Gruntfile.js and matching package.json are included in your licensed copy of the Toolkit. This Gruntfile has two targets, allowing you to create a clone of one of the example apps that ship with the Toolkit, or to create a basic 'Hello World' app.

Clone an example app via Grunt

In the root directory of your Toolkit files, run this command (this is assuming that you have Grunt installed on your computer, instructions for which are outside the scope of this document):

  grunt clone --app=database-visualizer --o=<your output directory>

Here we've cloned the database-visualizer app. You can clone any of the demonstrations that ship with the Toolkit. The full list is:

  • hierarchical
  • circular
  • absolute
  • spring
  • imageWidget
  • multiple
  • database-visualizer
  • flowchart-builder
  • hello-world
  • groups

If your output directory already exists, the clone will not proceed. Otherwise, the app will be cloned into the appropriate directory, and you can access it via the index.html. Remember to host the app with an http server and not try to use it by opening the local file.

Create an empty-ish app via Grunt

grunt create --o=<your output directory>

This will create a basic skeleton app in <your output directory>, with just enough functionality for you to see something working which you can then enhance and adjust.

Create an empty app manually

There are a million different ways to create a page from scratch, so here we'll talk only about the basic imports required:

CSS

jsPlumbToolkit-defaults.css (found in the /css directory) contains suggested defaults for your CSS, and it is recommended that you include it. Inside this file you will see comments for each style that detail whether or not it is an absolute requirement, or a suggestion, or just a cosmetic style used by the Toolkit to demonstrate how things should be setup.

Javascript

You need two JS imports, in this order:

  • jsPlumb Community Version 2.2.8 or later
  • jsPlumb Toolkit

And of course you'll likely have your own JS file containing your app code. Remember always to wrap your app's initialization like this:

jsPlumbToolkit.ready({

  // your code here
});

This method wraps jsPlumb's ready function and ensures that everything is in order before you start to make calls to the API.

Ingest an existing jsPlumb instance

This is a useful upgrade path for people who have an existing jsPlumb setup and wish to progressively make use of all the features the Toolkit has to offer. With this method you can instantly add pan/zoom capabilities to your UI, without making any changes to your current code.

It's very straightforward to ingest a jsPlumb instance:

  var renderer = jsPlumbToolkit.Support.ingest({
    jsPlumb:instance
  });

Here, instance is some instance of jsPlumb. What you get back is a Surface widget, which is ordinarily the result of a call to the render method of an instance of the Toolkit. The Surface canvas (the element on which you pan and zoom) becomes the jsPlumb instance's Container.

Accessing the underlying Toolkit

Usually when you work with the Toolkit you perform data operations on the Toolkit itself. To access this from the renderer variable returned from an ingest, call this method:

  var toolkit = renderer.getToolkit();
Suppressing Rendering

By default, the ingest method will configure a Surface from the jsPlumb instance's Container. You can suppress this behavior and get back just a Toolkit instance like this:

  var toolkit = jsPlumbToolkit.Support.ingest({
    jsPlumb:instance,
    render:false
  });
Supplying Rendering Parameters

You can also supply parameters for the Surface widget if you wish to:

  var renderer = jsPlumbToolkit.Support.ingest({
    jsPlumb:instance,
    renderParams:{
      consumeRightClick:false,
      clampZoom:false
    }
  });

Here we've instructed the Toolkit to enable right-click on the Surface (very useful when developing), and also to not clamp the movement of the UI when the user zooms. The default behaviour is to clamp the UI to prevent the content from disappearing if the user zooms in such a way that it ordinarily would.

Adding Nodes after Ingest

Once you've ingested your existing jsPlumb instance you have two options for adding new nodes:

  • Use your existing mechanism and advise the Surface via its ingest method. This method is added to any Surface that was created via the jsPlumbToolkit.Support.ingest method; it is not present on a Surface created via the Toolkit's render method. An example:
var renderer = jsPlumbToolkit.Support.ingest({ jsPlumb:instance });

/*
    time passes.

    eventually a DOM element - `el` - has been added to your UI. Now you want to tell the Toolkit about it.
*/

renderer.ingest(el);
  • Use the Toolkit's data binding mechanism to add and render new nodes.

To do this you will most likely want to supply a view in your renderParams. This defines a variety of things pertaining to the appearance and behaviour of the UI; the link provided goes through your options here in detail. A simple example:

var renderer = jsPlumbToolkit.Support.ingest({
 jsPlumb:instance,
 renderParams:{
   view:{
    nodes:{
      "default":{
        template:"tmplNode",
        events:{
          click:function(params) { alert("you clicked node " + params.node.id); }
        }
    },
    events:{
        "canvasClick":function() { alert("you clicked on the canvas"); }
    }
  }
 }
});

The point here is that renderParams supports the exact set of parameters as the params object on a render method call on an instance of the Toolkit. In this example we've provided the ID of the template to use to render nodes, and we've registered a click listener for nodes as well as for the whitespace in the work area.

Node Positioning

Nodes that have been ingested into the Toolkit will not have any positioning information stored in their backing data. If you wish to store the current positions, you can call this method at any time:

renderer.storePositionsInModel();

This will result in each Node's backing data having a left and top member. A common usage scenario is to call this immediately before you export the data:

renderer.storePositionsInModel();
var data = toolkit.exportData();

To reinstate positions at load time, for each Node you should call setPosition on the Surface widget:

 renderer.setPosition(id, left, top);

Here, id is the ID of the DOM element representing the Node. This is distinct from how the Toolkit organises IDs, but in the Community edition we have to use the element ID. So be careful that you set the correct IDs on the elements you create.