We are currently prototyping with GoDiagrams for .NET and have been extremely impressed, pleased, etc. with the ability to integrate graphs into a .NET environment. We are integrating with Drag/Drop functionality, interoperations with MS office, etc. and have had great successes in using GoDiagrams.
We are considering the possibility of implementing our full application in Java and would like to evaluate JGo for portability purposes.
My question is fairly basic:
Do we lose anything significant in going to a JGO/Java implementation as opposed to the .NET GoDiagram product? (Stability? Performance? Functionality?)
I had always wanted to write up a complete list of differences between JGo and GoDiagram, but the number of customers of one that are likely to want to use both is relatively small, so it never became a priority.
The biggest differences have nothing to do with Go but with Java vs .NET, both the languages and the libraries. An important subtle difference is that there are no structures passed by value in Java, so you need to be very careful about modifying Points, Dimensions, and Rectangles. This has made the JGo API messier than GoDiagram’s.
GoDiagram copied the JGo design but cleaned up a lot of things. Most are fairly small, for example, renaming JGoArea to GoGroup. When we add new features to GoDiagram we try to add them to JGo too, or vice-versa, depending on who’s first.
You’ll note that many of the sample applications are similar to each other too. In particular, you might find it useful to run Classier in both JGo and GoDiagram and compare the results.
The biggest difference, class-wise, is probably the lack of tools in JGo. GoDiagram tools were implemented by designing the IGoTool architecture and then porting the implementations of the tools from inside the implementation of JGoView. Then we added more tools.
There are several events that JGo doesn’t have built-in support for. And GoDiagram has additional predefined node classes, although some of them are in the examples directory in JGo.
Subgrouping with Collapse and Expand operations are a big part of the planned implementation in our final app. We are also using GoGroupList in building some fairly complex “composite node” types (like the Collapsing Record or Class nodes from the .NET Demo1). <?:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /><o:p></o:p>
Subgraphs looked great. I didn’t see a “collapsible” node in the demo for JGo. Are there any road-blocks to building a collapsible record node in JGo? <o:p></o:p>
Generally, the implementation times for .NET apps have been on a shorter cycle for us than comparable Java implementations - especially for client apps. Am I correct in assuming that this will probably be the case with GoDiagrams for .NET vs JGo?<o:p></o:p>
Thanks. As always, I really appreciate your excellent comments.
No, JGo is weak there compared with GoDiagram regarding built-in classes and interfaces, and predefined example classes. We haven’t copied over the IGoCollapsible interface and GoCollapsibleHandle class.
And there isn’t a class just like GoListGroup. Although the ListArea example class is similar to GoListGroup, ListArea supports scrolling and includes a scrollbar, which really changes the intent and usage. Maybe by stripping out the scrollbar from ListArea you can get something similar to GoListGroup. (But oddly enough, we just added a ScrollingMultiTextNode example class to Demo1 for GoDiagram 2.4.)
I’d agree with your impression regarding productivity when comparing Java client apps and Windows Forms apps.