[Biojava-l] Proposal for some changes in the SequencePanel cl ass.

[Matthew Pocock]

Hi Greg,

Both Sequence and Alignment inherit from SymbolList. If the sequence 
renderer JComponent swing classes were changed to accept SymbolList 
rather than Sequence, we can leave SymbolRenderContext as-is and all the 
renderers should continue to work without writing any new code. It is 
the responsibility of the rendering context to provide a symbol list and 
a feature holder object to the renderers, so this de-couples the GUI 
beany API from the sequence rendering API. In the case when a SymbolList 
instance that doesn't implement FeatureHolder is passed in, the 
renderers can be presented with FeatureHolder.EMPTY_FEATURE_HOLDER quite 
safely. Neary all of the rendering polymorphisms are in SequenceRenderer 
objects, not the swing classes.

At the moment, SequenceRenderContext is implemented by SequencePanel et. 
al., but in practice they do not need to implement this interface. They 
only need to be able to produce an instance of it to pass into the 
SequenceRenderer methods (such as for painting). The state stored by the 
SequencePannel (or other JComponent class) may not map 1-1 with that 
needed by the SequenceRenderContext interface. It seems cleaner (and 
less API bloat) if this is handled by a little inner class.

Matthew

Cox, Greg wrote:
> Hello Kalle,
> 
> This would create some problems for us.  Since alignments aren't sequences,
> I'd rather see a seperate class, AlignmentPanel, than overload
> SequencePanel.  Off the cuff, I'd suggest pulling the common functions up to
> a new class, AbstractPanel, and have both inherit from that.  Is there a
> reason this won't work that I'm missing?
> 
> I understand points 2 and 3, but I don't understand the use case driving
> point 1.  Could you recap the irc discussion for those who weren't there?
> 
> Regarding point 3, I'll observe that that EmblViewer doesn't call
> getSequence() anywhere.  I'm scanning our code to see if this would make our
> stuff blow up, but I'd rather not see it happen regardless.
> 
> Greg
> 
> 
>>-----Original Message-----
>>From: Kalle Näslund [mailto:Kalle.Naslund@genpat.uu.se]
>>Sent: Monday, May 13, 2002 1:27 PM
>>To: biojava-l@biojava.org
>>Subject: [Biojava-l] Proposal for some changes in the SequencePanel
>>class.
>>
>>
>>HI!
>>
>>I have a proposal for a change to the 
>>org.biojava.bio.gui.sequence.SequencePanel class. Currently the 
>>SequencePanel class only accepts  objects of type Sequence. In some 
>>situations the need to visualize SymboLists arise, for 
>>example when you 
>>want to display alignments that are in the form of Alignment 
>>objects ( 
>>that is what i want to do ).
>>I have informaly spoken to some of the people on the biojava IRC ( 
>>Internet Relay Chat ) channel and the response i got was that 
>>changing 
>>the SequencePanel class to accept SymbolLists would most 
>>likely be the 
>>prefered way to allow rendering of Alignment objects. I was also 
>>suggested that the current situation where the SequencePanel 
>>implements 
>>SequenceRenderContext should be changed, to a solution where the 
>>SequenceRenderContext is implemented by an inner class inside the 
>>SequencePanel class.
>>
>>To be a bit more precise, the changes would be the following:
>>
>>1. Move all methods from SequenceRenderContext to an inner class
>>2. Make SequencePanel accept SymbolLists by chaning void setSequence( 
>>Sequence s );
>>3. Change of the method Sequence getSequence(); to return SymbolList 
>>instead, as one
>>   no longer can be sure that we are rendering a Sequence. ( i assume 
>>this can break things )
>>
>>I have a working SequencePanel class that have been changed 
>>according to 
>>the description. And the EmblViewer demo already included in Biojava 
>>works without any changes. This hopefully means that change 
>>no 3 isnt a 
>>severe change, but comments on this is very welcome.
>>
>>So, what do you think about these changes, are they 
>>acceptable, or will 
>>they break some major thing for people ?
>>
>>mvh Kalle Näslund
>>
>>
>>     
>>
>>
>>_______________________________________________
>>Biojava-l mailing list  -  Biojava-l@biojava.org
>>http://biojava.org/mailman/listinfo/biojava-l
>>
> 
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
>