GWT Model Tab: Move graph implementation from JS to GWT

[GoogleCodeExporter]

Currently the implementation of the graph in the model tab is entirely made 
with Javascript.  Changing the implementation to be more GWT friendly would 
likely make it more easily extendable in relation to the rest of the client 
code, and will make debugging much easier.

The new object(s) will likely still need to have some JSNI methods in order to 
interact with the graph library, however (for things such as updating the 
layout and rendering objects), since the actual graph library is entirely 
Javascript.

Original issue reported on code.google.com by a.w.davi...@gmail.com on 18 Nov 2011 at 3:59

[GoogleCodeExporter]

This issue closely mirrors the kind of refactoring Tim had carry out on the 
code implementing the invariant tab. Reviewing the classes under 
synopticgwt.client.invariants might provide some insights on a good way to 
attack this issue.

Original comment by bestchai on 18 Nov 2011 at 4:08

• Added labels: GWT

[GoogleCodeExporter]

Original comment by a.w.davi...@gmail.com on 18 Nov 2011 at 4:33

[GoogleCodeExporter]

I think I'm going to move a few of Tim's classes (one's that don't seem to be 
intrinsically part of the synopticgwt.client.invariants package) into the 
synopticgwt.client.util package, then if that's alright.  I will definitely 
need to use his wrapper class for Raphael canvas.

CC'd Tim.

Original comment by a.w.davi...@gmail.com on 18 Nov 2011 at 4:45

[GoogleCodeExporter]

Sure, moving generic wrappers for Raphael functionality into util makes sense.

Original comment by bestchai on 18 Nov 2011 at 5:14

[GoogleCodeExporter]

It would be good to move Path and Label from invariants to util as well, those 
are generic wrappers.

Original comment by T.101.JV on 19 Nov 2011 at 10:27

[GoogleCodeExporter]

Note: There should probably be some retooling of the constructors, but Path and 
Label are designed to be generic.

Original comment by T.101.JV on 20 Nov 2011 at 12:22

[GoogleCodeExporter]

As of revision 21a42ab5b0f7 there have been a few updates.  The GWTNode class 
has been added to the synopticgwt.shared package.  All that's left is to add JS 
references to the respective edges/nodes, I think.

Original comment by a.w.davi...@gmail.com on 29 Nov 2011 at 6:39

[GoogleCodeExporter]

Let me know when you'd like me to review your code -- either now, or later when 
you're done with the issue.

Original comment by bestchai on 29 Nov 2011 at 6:45

• Changed state: Started

[GoogleCodeExporter]

There's still a few bugs I need to squish.  I've got to track down why there's 
RPC failures when fetching the final model, and why the handleLogRequest 
function in synopticgwt.client.model.ModelTab.java isn't returning any log 
lines (I suspect it's because I need to keep a copy of the corresponding 
partition node's hash code for that function).

Original comment by a.w.davi...@gmail.com on 29 Nov 2011 at 6:50

[GoogleCodeExporter]

Issue with grabbing log lines fixed as of revision aa3f0fe7bc9b, however 
there's still the occasional hiccup when grabbing the final model.  I'm still a 
bit stumped on it, so currently there's a line for printing out the strack 
trace when the RPC fails.  It's been printing out what's in the attached file.

I've yet to come up with anything useful from it, and it's a bit frustrating 
because it's very inconsistent (sometimes it'll throw an exception, and others 
it will be run very smoothly without a hitch for all of the example files, and 
even one's I've made up), so I'm not sure if it's something wrong with my code 
directly, or if it's only partially my code to blame.

Original comment by a.w.davi...@gmail.com on 4 Dec 2011 at 6:00

Attachments:

• stackTraceGWTNodeFinalModelRPCError.txt

[GoogleCodeExporter]

I might have resolved this bug earlier today. Before you do anything else, 
please try to replicate this bug on the default branch. If you cannot then it 
is likely that it's been resolved. In this case, merge default into the 
Issue164 branch (not the other way around!).

Also, I cannot see how this RPC failure impedes your work on issues 160-164. If 
you replicate the bug in default then file a new issue for it and provide the 
relevant details. But, I think that you should move on to solving the task 
you've been working on for a few weeks now, instead of concentrating on this 
bug.

Original comment by bestchai on 4 Dec 2011 at 8:27

[GoogleCodeExporter]

All seems quiet as of revision c8733b6fe4fe. Requesting code review.

Original comment by a.w.davi...@gmail.com on 5 Dec 2011 at 2:09

[GoogleCodeExporter]

Looks good. Merged into default in revision 7ae2374ce60f.

Original comment by bestchai on 5 Dec 2011 at 3:36

• Changed state: Fixed