My favorites | Sign in
Logo
                
New issue | Search
for
| Advanced search | Search tips
Issue 72: Refactoring of Vizigator to allow for new implementations
2 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  larsga
Closed:  Aug 21
Type-Enhancement
Priority-Low
Component-Vizigator
Release5.0.1


Sign in to add a comment
 
Reported by MCarter.TDKC, Jul 10, 2009
Refactor of the vizigator code to allow for additional implementations
beyond VizDesktop and Vizlet.

This requires several steps:

1) pull the ApplicationContextIF and implementations out of VizContext and
make full classes (instead of internal classes)

2) create an interface / abstract class for the vizigator front end (i.e.
VizDesktop and Vizlet) so that the UI is independent of the front end and
instead only access this abstraction, thus allowing for other front ends to
be developed (i.e. eclipse plug-in).

When complete, there should be no impact to the existing vizigator front
end implementations.
Comment 1 by MCarter.TDKC, Jul 16, 2009
I have attached the changes for this.  The zip file contains all the class files,
which includes 5 new files.  I have also attached the output of svn diff as well.

Thanks

Mike Carter
ontopia.zip
52.3 KB Download
diff.txt
24.6 KB Download
Comment 2 by larsga, Jul 17, 2009
Have worked a bit on the patch, but it needs more work. See mailing list for 
details. Attaching new zip.
vizpatch.zip
61.5 KB Download
Status: Accepted
Labels: Component-Vizigator
Comment 3 by MCarter.TDKC, Jul 20, 2009
Newest revision, correcting the VizLet error as well as cleaning up and documenting
the new interfaces.
patch_72_2.zip
66.8 KB Download
diff.txt
33.1 KB Download
Comment 4 by MCarter.TDKC, Aug 03, 2009
Any updates on this latest revision?
Comment 5 by MCarter.TDKC, Aug 17, 2009
Lars - when do you think you will have a chance to look at this latest patch?
Comment 6 by larsga, Aug 18, 2009
I've looked through the patch and it's looking a lot better. This version I think is 
very nearly there. However, there are still some bugs in Vizlet:

(1) "Topic type configuration" in the context menu brings up association config.
(2) Existing configurations (such as for the opera topic map) do not load. Instead
    the vizlet uses a default configuration.

Finally, I'm kind of wondering whether ApplicationContextIF and VizController do not 
in reality serve the same purpose. Should they perhaps be merged? What do you think?

I'm attaching a modified version of the code.
patch-72-3.zip
153 KB Download
Comment 7 by MCarter.TDKC, Aug 18, 2009
Thanks - I'll look at your changes and see what else I need to do to fix these vizlet
issues.

As for ApplicationContextIF - This pulled the code out of VizController so that front
end implementations did not have to modify it.  It is all code that VizController
calls, but that may have differences between how it is running - i.e. between
Vizigator and Vizlet.  This enables me, in the end, to write a new front end for our
application by implementing this interface outside of the core code.  

Thanks

Mike
Comment 9 by MCarter.TDKC, Aug 19, 2009
Issue (1) is fixed, however I am completely unable to recreate issue (2).  If there
is a custom configuration (.viz) file, then the JSPs pick it up, and if not then the
maps are displayed without it.  I tested it by removing the .viz files for several
maps (including the Opera topic map) and verified that it works.

I made no changes in the JSP files - only to java code.  The custom configurations
are picked up by these and handed down to the code - the java code never see the
original file (be it .ltm, .xtm or .viz).

Thanks

Mike
Comment 10 by larsga, Aug 20, 2009
Yes, the JSP files do the right thing.

However, when I try to visualize the Italian Opera topic map it is displayed without 
the configuration that was set up for it. That is, all nodes and edges have the 
default formatting, and the colour scheme is random. That implies to me that 
although the configuration parameter is provided to the Vizlet, the Vizlet is not 
loading and using that configuration.

If you cannot reproduce this at all, let me know, and I will retest more thoroughly.
Comment 11 by larsga, Aug 20, 2009
(No comment was entered for this change.)
Owner: larsga
Comment 12 by MCarter.TDKC, Aug 20, 2009
I am unable to recreate this at all.

For all the topic maps that come with the build (located in
ontopia-5.0.0\apache-tomcat\webapps\omnigator\WEB-INF\topicmaps ) it seems to be
working correctly.  If the .viz file is there, then it uses it, if it is not then the
map is displayed using the default values.

I have attached a screen shot of the opera topic map in the vizlet with the .viz and
without the .viz file.  This works the same way in the VizDesktop as well, as it should.

I am also attaching my latest changes for the other fix so you have everything I have
up to date.  

Mike


opera-viz.jpg
69.8 KB Download
opera-noviz.jpg
74.2 KB Download
patch_72_4.zip
65.9 KB Download
diff.txt
32.3 KB Download
Comment 13 by larsga, Aug 21, 2009
It turns out that your code was perfectly fine after all. The problem was with my 
setup. My apologies for any unnecessary work this may have caused you.

We've discussed the design issues in this patch a bit here, but decided in the end 
to accept it as is. We can always fix any design issues later.

If you could add javadoc to ApplicationContextIF (like you did for VizFrontEndIF) 
that would help enormously to make this code more maintainable in the future.


Comment 14 by larsga, Aug 21, 2009
This issue was closed by revision r429.
Status: Fixed
Comment 15 by MCarter.TDKC, Aug 21, 2009
Sorry I didn't add the java doc - I didn't think about it since I lifted most of this
straight out of the the old VizController class.

Thanks for your help.

Mike
ApplicationContextIF.java
3.5 KB Download
Comment 16 by larsga, Aug 25, 2009
Javadoc now added in revision 444. Thank you!
Comment 17 by larsga, Sep 01, 2009
(No comment was entered for this change.)
Labels: Release5.0.1
Sign in to add a comment

Hosted by Google Code