Converting GoXam to GoJS

Hi,
I have a big question: what is required to convert GoXam application to GoJS application?

In more details I would like to know how to you suggest to handle client events such as creating link, dragging node, etc.
After all I will have to load the diagram data from the server and will have to save the data back to the server. It is possible to do it piece by piece or in single batch but it will be done sometime.

Also it is interesting to me how can I customize a node and link. WPF has rich template and binding, how do you do it in JS?

It looks like you are still the best solution for diagrams, keep up the great work.

Ido.

First, I’d like to say that if you have a WPF application, there is no reason to switch to JavaScript/HTML unless you need to target that platform. I think in most cases it will be Silverlight applications, not WPF, that will be ported to HTML5, because one had chosen Silverlight in order to target browsers on Windows and Mac. And it is a lot easier to port a Silverlight application to HTML5 because of the client/server application architecture and the rich client functionality.

Second, as you already know, GoJS is necessarily not source-code compatible with GoXam. Coding is in JavaScript, not C# or VB. UI design is in JavaScript, not XAML XML.

I suppose we could have called GoJS’s UI design definitions “JSAML”, but we have not, to avoid raising expectations too much. And anyway, although there are a lot of similiarities between GoJS GraphObjects and WPF/Silverlight FrameworkElements in the essential ideas, there are too many differences in the classes to permit mindless conversion from XAML to GoJS.

Instead we have tried to redesign all of the basics from WPF/Silverlight needed for nodes and links to be appropriate for modern JavaScript and yet also be clean and elegant. I think what we have is close to a minimal API and yet it provides almost all of the functionality of GoXam. There are some GoXam/WPF/Silverlight features that are not currently supported, such as drop-onto behavior and printing, because we haven’t had time to redesign them. And there are some features that we purposely postponed, such as animation, because we knew that we would not have time to design and implement them.

But there is a lot that is basically the same as in GoXam. A Diagram has a CommandHandler and a ToolManager to handle InputEvents. There are a lot of the same tools, plus a couple more because there is no WPF/Silverlight framework that we can depend on. (They handle context menus and “mouse actions”, and were taken from GoDiagram.) The DiagramPanel and PartManager classes have been merged into the Diagram class.

There is a GraphLinksModel class, but it is a lot simpler than in GoXam. Some of its functionality has been moved into the diagram, but most of its basic responsibilities remain the same. There is no TreeModel yet, but we intend to provide it someday. The UndoManager is pretty much the same.

Templates are similar to DataTemplates in WPF/Silverlight, but they are much simpler. Yet they can be copied, unlike DataTemplates, to create Parts or Panels bound to data. Data binding is similar but also simpler. There are no converter classes – just JavaScript functions. As you can see in the intro or the samples, defining and customizing Node templates or Link templates is similar. The syntax is JavaScript instead of XAML, of course, and the particular properties that you data-bind are different, and binding is limited to simple properties, not property paths.

The predefined Layout classes are basically the same, except there is no MultiLayout. But the LayoutManager functionality has been merged into the Diagram class.

The Part/Node/Group/Link/Adornment classes are similar to GoXam’s, although in GoJS Adornment inherits from Part instead of Node. The Route class has been merged into the Link class. Unlike in GoXam, one can create Parts in GoJS, which is useful for diagram decorations that are not Nodes or Links. The notion of “ports” is the same in GoJS as in GoXam – defined by setting properties (attached properties in GoXam) on whichever Node elements that you want.

There is a single Panel class that implements the functionality of the important WPF/Silverlight panel classes along with the important diagram panel classes (Node, Spot, Link, Grid[Pattern]). The GoJS Placeholder class supercedes the GroupPanel of GoXam inside Group templates, and the Placeholder is used for Node Adornments too.

There is a single Shape class instead of the several Shape classes of WPF/Silverlight. But it supports the same set of predefined figures that GoXam has. Shape also implements support for predefined arrowheads.

The Palette and Overview classes are just like in GoXam, except that the implementation of Overview is completely different (and more like GoDiagram’s).

I’ve gone on in a bit more detail than I expected. Perhaps I should add more details in a more comprehensive page in the Introduction.

Thank you for the details.
Off course the transition from WPF to JS is not simple.
We think on convert or more remake some parts on the web to allow more customers access.
I’ll try playing with it.

Have you try using GoJS with framework such as Ember?

Thank you again.
Ido

I’m not familiar with Ember.

Since GoJS templates and binding operate within the context of diagram data and objects rather than HTML DOM elements, I’m not sure that there is much overlap.