I’m supervising a client to pick a platform for a porting an old app to .NET platform. There are lots of graphs and schemas used in the app today; although only static bitmaps with direct drawing using x/y coords. I want access to all nodes and edges programmatically. I also want to store a graph config in an xml or similar to more easily adapt to changes in the graph model.
I colleague of mine suggegest I should evaluate Northwood's components - and I must admit they look very promising.
I tend to opt for a fat client solution (don't favour too much javascripting + browser variations) - app is to run inside customers walls anyway - but then again have to select either WPF or WinForms. WPF obviously brings an added challenge of the new programming paradigm, but I'm also wondering if I can get an [unbiased] rating on the maturity of GoXam (1.1.3.4) vs GoDiagram (4.1.0) for WinForms...? I would guess they are rather different in implementation - and the version numbers indicate different braches in development? Is GoDiagram more stable than GoXam since it has been around longer?
GoDiagram is more mature than GoXam in most respects, but there are a
number of non-platform-dependent features that only GoXam has. So GoXam is not a proper subset of GoDiagram.
Their designs and implementations are quite different, although there were many significant pieces of code that were ported from GoDiagram to GoXam. GoDiagram tends to require more programming than GoXam, but for that reason it also tends to have more flexibility.
So GoDiagram is more stable than GoXam. But I believe most programmers think they are more productive in WPF and XAML than in WinForms and code. And the resulting applications look nicer and feel smoother.
Conversely, XAML/data-binding/templates/styling is distinctly slower at run-time than the GoObjects we defined in GoDiagram. If you expect to have many thousands of nodes or more in your diagrams, you should use GoDiagram.
Just to bring in GoDiagram for ASP.NET as well; depending on potential changing client requirements - it might be the preferred target platform after all...
-Would you say GoDiagram development would be more time consuming for asp.net vs. winforms?
-I guess it can be more challenging to implement advanced UI features in asp.net than winforms? (drag/drop, operations requiring javascript etc.)
-It seems in det aspx-demos that there are small variations from browser to browser (I've run demos using IE, Firefox & Chrome) - in general, are there many pitfalls with goDiagram and cross browser compability?
GoDiagram for ASP.NET (a.k.a. GoWeb) is a thin-client solution where almost all of the work is done on the server. It’s hard or impossible to implement very interactive diagramming features, but almost all standard gestures produce the expected results, including drag-and-drop both within a Diagram as well as from a Palette to a Diagram.
Yes, we have tried to implement the same features on all browsers, and there are some variations that we could not avoid. But I think you don’t need to worry about it unless you try to do a lot of JavaScript programming on the client. In which case using a rich-client solution such as Silverlight might be best after all.