Answer below
2016-03-24 19:29 GMT+01:00 Zieris, Franz <franz.zie...@fu-berlin.de>:
> Hi there,
> ...
>
> (2) The second problem still bugs me: Upon deserialization (from JSON back
> to
>
Java objects), GSON naturally needs to create instances for the
> non-primitive
> fields of the classes. In the case of ProjectTree these non-primitive
> fields
> are 'root' (of type ProjectTreeNode) and 'displayName' (of type
> String).
> GSON can handle that easily.
> But for ProjectTreeNode, there is a field 'path' of type IPath, which,
> of
> course, has no ctor as it's an interface.
> Consequently, GSON prompts the following error:
> "java.lang.RuntimeException: Unable to invoke no-args constructor for
> interface
> de.fu_berlin.inf.dpp.filesystem.IPath. Register an InstanceCreator
> with Gson
> for this type may fix this problem."
> Using an InstanceCreator sounds like a solution for this problem (I
> didn't try
> it yet), but I cannot help but ask:
> Has actually *no one* *ever* tried to call the SendInvitation browser
> function
> yet?
> Because if s/he had, s/he must have stumbled upon the same problem:
> IPath
> cannot be instantiated!
>
>
I tried it with Basti and the SendInvitation() browser functions worked. We
shared a project (in Eclipse) with this method in a session. I spend an
hour figure out how it could worked. (because you absolutely right, the
desalinization of a ProjectTreeNode must fail). I didn't find an
explanation, maybe we tested it with a different version than the one that
made it in the master. I think I changed the String path field later to
IPath and didn't test it again. Something on those lines.
Some Remarks about this (besides a lot of stuff that can be simplify in the
ProjectListManager:
* The IPath don't need to be serialized, it might not even be needed at all
in the model. It only function as a key for the IResource mapping. This can
also be done with another (easy serializable) fieldtyp.
The other usage is the creation of the 'displayName' field, what can (and
should) be directly created with IResource.getName() instead of using the
path. I wouldn't bother implementing a InstanceCreator.
*The deserialization of the proejct model(s) might not be necessary at all.
It would be much easier (from a Java perspective) to call SendInvitation
with a set of keys for the desired nodes. Something like:
SendInvitation(String projectName, String[] projctTreeNodeKeys) -->
__java_sendInvitation("MyProject",{"rootproject/src/foo.java","rootproject/src/foobar.java"});
I don't know how *hard* it is to extract the fields of the json and return
only the needed keys. But it's much better than to send a whole json back,
that is already there (saved in the ProjectListManager).
This would also simplify the fix for the performance problem (Bug 861 [1]).
I have a local version of this approach, but didn't find the time to fully
worked it out yet.
* As the test coverage of UI project nearly zero, this refactoring (along
with all other stuff that happens there) has a *high* change of introduce
new errors. so my plan was to develop *any* new stuff for this project with
TDD. This also helps me to avoid a lot of little mistakes, and I am kind of
frustrated with all the little and big bugs inside it. Sadly I don't will
have time for this until April. But I would like to see you test cases if
you need review.
[1]https://sourceforge.net/p/dpp/bugs/861/
Best
Matthias
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
