Details
-
Type:
Improvement
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:
-
Story Points:3
-
Epic Link:
-
Sprint:Spring 2019 Sprint 4, Spring 2019 Sprint 5, Fall 2019 Sprint 2, Fall 2019 Sprint 3, Fall 4 : 30 Sep to 11 Oct, Fall 5 : 14 Oct to 25 Oct, Fall 6 : 28 Oct to 8 Nov, Fall 7 : 11 Nov to 22 Nov, Fall 8 : 25 Nov to 6 Dec
Description
IGB implements REST endpoints that trigger loading of genomes and data files. This code is supporting IGB bookmarks, Galaxy and CyVerse bridges, and BAR connectivity.
Currently all the code is written in one place and is handled based on conditions. It makes the code highly complicated, hard to read, and hard/risky to modify.
Goal: Develop a strategy to re-architect this code to make it easier to understand and modify.
Files to look at:
IGB:
- BookmarkUnibrowControlServlet.java
- BookmarkHttpRequestHandler.java
BioViz:
- bar.js
- galaxy.js
- cyversetoigb.js
Important Urls for testing:
BAR:
Galaxy:
CyVerse (You can use testing environment for Bioviz. Take credentials from Cyverse Team):
- bioviz.org/cyverseData.html
Also, you should look at the REST endpoint we wrote to trigger installation of IGB Apps. Ask Riddhi and Charan.
Attachments
Issue Links
Activity
Refactoring Strategy:
All requests will have a this format: localhost:PORT/igb/SOURCE/ACTION. Source will be one of these (Galaxy, Bar, IGBApp, CyVerse, Bookmark, etc). Actions would be get/post requests coming from those sources. The parameters would be added in the body of the request.
There would be a parent RequestHandler, different Sources will extend the Common request handler to handle their respective requests. This would make the code modular. Generic methods and implementations will go in the parent handler. This will achieve separation of concerns.
Dr. Loraine, is this approach in the right direction?
I think we should implement this using declarative services, similar to how IGB allows Apps to add new menu items to "Tools" and other top-level menus.
This feature is implemented via a "menu api".
See: https://bitbucket.org/lorainelab/super-simple-igb-app for a simple example.
SuperSimpleIgbApp implements MenuBarEntryProvider, an interface in API package org.lorainelab.igb.menu.api. SuperSimpleIgbApp is declared as a "Component" configured to start as soon as it is installed - using the "@Component immediate=true" annotation.
Meanwhile, corresponding @Reference annotations in MenuBarManager (in com.affymetrix.igb.util) annotate methods that accept MenuBarEntryProvider objects, such as SuperSimpleIgbApp.
When a user installs an IGB App that implements MenuBarEntryProvider and contains an @Component annotation, any @Reference methods belonging to other @Component methods which accept MenuBarEntryProvider objects get invoked. These "@Reference" annotations "inject" MenuBarEntryProvider objects into corresponding @Component objects.
The "manager" merely adds or removes the menu items from the GUI. It does not dictate what the menu items actually do. Other code does that.
I am thinking we need something similar - a "REST request" manager that will forward requests to all endpoints that have been added.
Looking into possibly using RouterNanoHTTP
CyVerse needs an endpoint!
This task is very open-ended. I think we have done sufficient documentation for first stages of this. Closing.
Also should look at:
The above implements a REST endpoint for managing IGB Apps.