New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring of Vizigator to allow for new implementations #72

Closed
GoogleCodeExporter opened this Issue Mar 16, 2015 · 17 comments

Comments

Projects
None yet
1 participant
@GoogleCodeExporter

GoogleCodeExporter commented Mar 16, 2015

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.

Original issue reported on code.google.com by MCarter....@gmail.com on 10 Jul 2009 at 1:03

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

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

Original comment by MCarter....@gmail.com on 16 Jul 2009 at 5:54

Attachments:

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

Have worked a bit on the patch, but it needs more work. See mailing list for 
details. Attaching new zip.

Original comment by lar...@gmail.com on 17 Jul 2009 at 1:56

  • Changed state: Accepted
  • Added labels: Component-Vizigator

Attachments:

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

Newest revision, correcting the VizLet error as well as cleaning up and 
documenting
the new interfaces.

Original comment by MCarter....@gmail.com on 20 Jul 2009 at 5:14

Attachments:

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

Any updates on this latest revision?

Original comment by MCarter....@gmail.com on 3 Aug 2009 at 12:40

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

Lars - when do you think you will have a chance to look at this latest patch?

Original comment by MCarter....@gmail.com on 17 Aug 2009 at 12:17

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

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.

Original comment by lar...@gmail.com on 18 Aug 2009 at 1:49

Attachments:

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

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

Original comment by MCarter....@gmail.com on 18 Aug 2009 at 1:59

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

[deleted comment]
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

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

Original comment by MCarter....@gmail.com on 19 Aug 2009 at 5:37

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

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.

Original comment by lar...@gmail.com on 20 Aug 2009 at 9:16

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

Original comment by lar...@gmail.com on 20 Aug 2009 at 9:16

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

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


Original comment by MCarter....@gmail.com on 20 Aug 2009 at 11:53

Attachments:

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

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.


Original comment by lar...@gmail.com on 21 Aug 2009 at 12:15

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

This issue was closed by revision r429.

Original comment by lar...@gmail.com on 21 Aug 2009 at 12:15

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

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

Original comment by MCarter....@gmail.com on 21 Aug 2009 at 12:42

Attachments:

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

Javadoc now added in revision 444. Thank you!

Original comment by lar...@gmail.com on 25 Aug 2009 at 11:29

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 16, 2015

Original comment by lar...@gmail.com on 1 Sep 2009 at 11:41

  • Added labels: Release5.0.1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment