Hi all. This is a request for comments.
I thought it worth resurrecting a conversation Mungo and I started back
in January about deciding what packages should have what code. For OSGi,
we need to have clear separation between concrete GUI implementations,
and core modules implementing the datamodel, IO, analysis, rendering,
and view/model/controller functions.
Please have a look at the discussion below. Email comments/revisions to
this thread, and I'll integrate all into a master document as we develop
our 3.0 vision. For now, its also worth reviewing code you've created to
see how it fits with these guidelines....
Jim.
On 07/01/2015 11:06, Mungo Carstairs (Staff) wrote:
I don't know if you are online today, but if so could you remind me
of the rules about what is, or in particular isn't, allowed to go in
the jbgui classes?
The rule with jbgui is that it should only include platform gui
implementation code. No application GUI logic (although there are some
exceptions which should be fixed re certain menus), and absolutely no
controller/datamodel/view logic. There's a much longer braindump below
that I'd like to refine to some working rules for all of us.
But.. read on first.
Reason: I have been refactoring the duplicated code in AppJmol and
ChimeraViewFrame into GStructureViewer in my local branch. I suspect I
may have overdone it, and need instead to create a common base class
in the gui package.
nooo! The refactoring strategy here needs to be independent of the
jbgui package.
As I see it, the parallels are that Chimera is a peer for viewing
structure data mapped to sequences shaded according to current alignment
view state and can take commands to create superpositions according to
alignments. All these functions are GUI independent, but map to logical
structureViewer operations so they should be in a non-gui controller
package that implements a structureViewerModel API that Jalview's GUI
can employ.
Unlike Jmol and MView, Chimera doesn't provide a rendering window, so
the concrete GUI implementation for Chimera only serves as a proxy for
the external chimera instance. Its geometry needs to be preserved on
restore, but the way that chimera sessions are saved and restored is
different to Jmol, so that functionality shouldn't be shoehorned into
the same inheritance model.
More generally, thre refactoring rule I'm following is to introduce a
non-GUI dependent model wherever possible that is employed by a GUI
class to maintain state, *allowing multiple GUI implementations to
employ the same core logic*. This gets around Java's lack of support for
multiple inheritance, and to avoid lockin to particular Java platform
APIs that may not always be available. jbgui classes are only necessary
for concrete swing windows, and it only makes sense to inherit from the
same jbgui class if the end products are different flavours of the same
swing window.
Now, the braindump.. which - as mentioned is a work in progress..
The basic rules I have been following are:
1. Refactor or implement data views and associated get/set/modify logic
to concrete classes which implement interfaces defined in jalview.api.
The first one of these was the Viewport.
2. Keep Desktop or applet specific model/state logic in gui and appletgui.
This bit needs to change [in order to create Jalview 3.0]. Originally,
each one contained runtime/setup logic, actions to execute data analysis
steps and construct new views from the results, and view state analysis
code to make the GUI reflect current model state. What we ideally want
is a full separation... so:
3. Refactor any control logic to classes in jalview.controller - should
only import from non-gui packages.
4. Place any code dependent on both jalview and non-jalview APIs in ext.
5. Insulate GUI API dependent code (e.g. swing, awt, etc) from jalview
by creating flyweight or wrapper classes implementing jalview
interfaces.***** these are UI interfaces, not model interfaces - suggest
these will live in a separate subpackage of the api **
*
Currently, the jalview2xml logic doesn't follow the above at all.
Ideally we should have a factory/GUI service interface which takes
jalview view/datamodel objects, that is initialised at runtime according
to jalview's mode (e.g. running on swing, android, web, etc...).
For OSGi, I envision one or more Jalview executable modules that can be
told which GUI implementation to use, and autodiscover any other
available modules for runtime functionality (database accession sources,
database search interfaces, file parsers, alignment and analysis
methods, rendering systems) that are compatible with runtime
configuration (e.g. sandboxed applet, full desktop application, headless
commandline analysis engine, android app, etc).
_______________________________________________
Jalview-dev mailing list
[email protected]
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
