[Pipet Devel] GST, widgets & figure building

[Alan J. Williams]

On Wed, 23 Jun 1999, J.W. Bizzaro wrote:
 > Yes. Yes. Yes. Yes. Yes.  What were you thinking?  I guess we are on different
 > planes of quantum reality, but we'll hammer things out ;-)

I was just thinking of the data as the objects and the
programs/modifiers/translaters/etc... as the lines. 

 > That pretty much sums it up.  Except, Viewers are widgets+ that handle
 > ViewerItems, which are graphical objects, and Figure Builder is one "big" Viewer
 > running as a separate application.  The user can then copy/paste or drag/drop
 > multiple graphical objects (ViewerItems) onto the FB.  This allows the user to
 > choose only the Loci-generated figures they want for an illustration.  What were
 > you thinking of?  Is there anything wrong with this approach?

That's what I was thinking as well. I guess the issue is how do we go
about implementing this.

 > I agree with you.  I'm not sure why you think I combined the Translator and
 > Viewer.  Maybe saying "ViewerTranslator" is confusing.  I only wanted to show
 > that the Translator is specifically for Viewers.  So, ViewerTranslator ==
 > Translator.  Sorry, I deleted the diagram.

I think I finally see what you mean by translators and their role in Loci!
See below...

 > You mean something like a composite widget?

Basically what I was calling the ViewerItemWrapper is the combination of
data objects and widget objects into one self-contained object that could
be embeded into the Main Viewer.  I think this is what you are think as
well.

 > Yep.  This whole "what format is best for object transfer?" problem is what
 > Justin and Humberto have been working on.  We'll have to come up with something
 > soon.

Somebody in one of the other recent posts mentioned that DOM2 allows for
filtering of the elements on the server side.  It sounds like a
combination of SAX/DOM2 might be the way to go (although I know next to
nothing about DOM). The next question is whether we provide a single
interface to the XML data or several? 

 > That sounds good.  (Technically though a gene prediction program would be a
 > "Modifier" that is linked to a Translator ;-)
...
 > (Translators sandwich everything.)  Now this has nothing to do with a Viewer,
 > but if the user wants to add a Viewer, they have to add these loci:

Oh, so that is what translators are! But it would seem to me that we don't
need translators to sandwich everything.  For instance an viewer for
sequences should understand sequence documents directly.

 > We can make a whole set of arguments for an annotated sequence or any other
 > graphical bioinformatics object.  This information can be stored/passed in a
 > markup document.

Just to be sure we are on the same track, by "information" you mean the
"how to display feature X information" which goes in the markup document
and the "where/what is feature X" goes in the annotated sequence document.

 > That's a good question.  I thought about that while coding the Workspace, and it
 > seems I may need another XML to store an entire WorkFlow Diagram, in case it
 > needs to be restarted.  The Workspace can even be something the user can
 > New/Open/Save/Close as if it were a wordprocessing document.  I think this
 > should be tied into the whole "Electronic Notebook" idea, since the EN and the
 > Workspace will be managing the same information.  Interesting.  Any thoughts?

So we have the workspace which is used for:
     1) Setting up a new analysis flow
     2) Track currently running analysis flow

Now for the notebook we want to track what analysis were run and what
documents were generated.  So we have a xml fragment for the analysis that
was run.  This allows us to redo the analysis, restart the analysis, find
what docs the analysis produced, modify the analysis.

Furthermore, when setting up the flow, we should be able to insert a
document type to indicate that we want a permanent record of that data
(even if it is in the middle of an analysis flow).  So for instance:

     Seq Doc --> Digest Mod --> Digest Map Viewer

would show a digest map to the user, where

     Seq Doc --> Digest Mod --> Digest Doc --> Digest Viewer

would not only show the map, but store a copy of the results. 

In a perfect world you wouldn't need to store the itermediate, you could
just regenerate it from the flow info in the notebook, however lets say
there was (God forbid) a bug in the Digest Mod that caused a restriction
site to not be recognized.  So I run the analysis, figure out what enzymes
to use, do my subcloning, get the new clone sequence, and and find out
that I have the wrong section of sequence.  I go back to show my PI the
initial analysis I did but because the bug was fixed, my digest now shows
the extra site! This is why we need to be able to document not just how to
generate the data, but we need to be able to store and track the data that
is generated.

 > This may be related to the first question, but yes.  There will be lots and lots
 > to manage.  Perhaps Loci will make the most use of different XML's of all other
 > programs before it.  I think everything will be linked, even different XML's,
 > and this would be done by cross-referencing.  At the highest level we will have
 > the Workspace, and at the lowest level, maybe the biodata.  Loci will be a big
 > challange for some XML "X-perts".

Sounds good.

 > Justin has been with the project for a while and set up the original mailing
 > list.  The archive is still up.  There's lots of design talk in those old
 > messages.  It's probably a good way to get the feel for where Loci is going.
 > 
 >     http://toaster.sped.ukans.edu/tulip-list/

Thanks.

 > But again, so much has changed.  We'll just have to see how it turns out in the
 > end :-)  Everytime I try to write something, it's incomplete because the
 > implementation is unclear, and then everything changes a week later after a few
 > messages have been passed.  And often just doing some coding takes us down a
 > different path, as with the Workspace.
 > 
 > Some people are very good at planning every move.  I hope that leaving a few
 > things up in the air will allow for some innovation and creativity.  For
 > example, I think you contributed a great deal to the design already :-)  Some of
 > what we've been talking about were not very clear to me before.

I agree. Planning is essential, but there is a lot that changes when I
start to actually code.  Inevitably I will get a project half coded and
then decide that I did it total wrong. Then I start coding all over.


************************************************************************  
Alan Williams           
------------------------------------------------------------------------  
University of California, Riverside   "Where observation is concerned,
Dept. of Botany and Plant Sciences     chance favors the prepared mind."  
Alan at TheWilliamsFamily.org                         -- Louis Pasteur
************************************************************************