I just came up with yet-another-way-of-making-a-Bioclipse-Manager

There are a few things not so very nice with the way of implementing a manager called "The New World Order". Before you all give up muttering something about things changing all the time I want take this opportunity and say that it is not so easy for a bear of very little brain and I need a few iterations to get things decent. Furthermore I want to say that I am not forcing you to do your managers in a certain way and that there is nothing stopping you from doing your manager without Spring and all my fancy inventions -- of course you won't get recording, automagic job creation, translation from String to IFile and all that stuff , you will have to do it yourself, nevertheless if that is want you want I won't stop you.

Now for the list of things not optimal with "The new World Order".

1. Most importantly. All the methods defined in the interface but not implemented in the manager. Yes those pesky "This manager method should not have been called"-ones.
   
2. Ola raised the problem of calling multiple long running jobs parallel in one job and then wait for all of them to finish. Something I can definitely see would be useful when doing things like QSAR calculations on any computer with more than one core (basically that means any machine these days...).

So much for the background here comes the suggestion. First of all in order to get rid all the methods that we don't want to implement the manager will not implement the manager-interface -- no more XManager implements IXManager. When doing managers in this way the coupling between the manager and the interface is loose. The actual dispatching of methods would be done by a MethodInterceptor which would catch all method calls on the manager and call the right method with the right arguments.

Basically I see the need for three different sort of methods when dealing with long running operations. I will show with 2 examples. First a method receiving a BioObject and returning another BioObject.

Methods on the interface

public IMolecule 
       generate3dCoordinates( IMolecule molecule );

public void generate3dCoordinates( IMolecule molecule,
                                   BioclipseUIJob uiJob );

public BioclipseJob
       generate3dCoordinates( IMolecule molecule,
                              String jobName );

First we have the standard method that will be used from JavaScript and that will be run in the gui thread (freeze Bioclipse) if run from Java. Next is another old friend but in a slightly different appearance. This is the method used when writing actions in context menus for example. It is void (we can't hang around waiting for the result) and creates a Job. The code updating the GUI afterwards is given through the BioclipseUIJob -- in the method named runInUI. Finally we have a new friend. This method returns a job. This method is meant to be used from other manager methods. For example imagine a method in some fancy Manager. Our method needs to generate 3d coordinates for a bunch of molecules and than do some fancy calculations on all of them. The idea is that you can write it a little bit like this:

BioclipseJob job1 
    = cdk.generate3dCoordinates(mol1, "first job");
BioclipseJob job2 
    = cdk.generate3dCoordinates(mol2, "second job");
job1.join();
job2.join();
IMolecule mol1With3d = job1.getResult();
IMolecule mol2With3d = job2.getResult();

So each cdk.generate3dCoordinates call will be a job of it's own. By the way the String jobName paramater must be there or the third method's signature will clash with the first one.

All this will be accomplished by one method on the actual manager implementation. It will look something like this:

Method in the Manager class

public IMolecule
    generate3dCoordinates( IMolecule molecule, 
                           IProgressMonitor monitor );

All the translation from the methods declared in the interface to this method will be done by the MethodInterceptor which of course comes in one flavor for Java and one for JavaScript.

Let's look at one more example. This one is for working with files and contains the String -> IFile conversion.

Methods on the interface

public IMolecule loadMolecule( String path );

public void loadMolecule( IFile file, 
                          BioclipseUIJob uiJob );

public BioclipseJob loadMolecule( IFile file,
                                  String jobName );

This is basically business as usual by now. The String -> IFile conversion would also be done by the very same MethodInterceptor.

Method in the Manager class

public IMolecule loadMolecule( IFile file, 
                               IProgressMonitor monitor );

So, what does this solution lack? :)

I just wish I could reach the Eclipse help articles writers with this post

Today I printed an eclipse help article and read it. At page 10 out 13 I found what I was interested in. Some code. But the dabbler who wrote the code used a line width of of something like 94 columns or so and of course the printed version does not show the end of such crazy long rows. So the thing in the article that I was actually interested in was lost when I printed it.

Now if only people could keep their code within a limited number of columns. That would not only make it possible to print the code, but also read the code on screen without having to scroll horizontally.

I just need to make sure all the manager implementations are up to date now I suppose

I am beginning to feel happy with the Bioclipse manager documentation on the Biclipse wiki. There are probably a zillion small errors and things to add to it but at least it contains what I right now think are the most important parts. Now I must make sure that all managers that are going to be included in the Bioclispe 2 release candidate are implemented according to this scheme. Time to file bug reports! :)

I just started to (finally) write the documentation for Bioclipse managers

I have been pushing it in front of me for quite too long a time now. But now (finally) I have started to write the text on How to make a manager on the Bioclipse wiki.

I kept telling myself that there where no point in doing it since I want to modify the process anyway. I guess that will have to be post Bioclipse 2.0 though. The main problem with the current solution is that it contains methods with this not so very nice look:

   public void remove( String filePath ) {
      throw new IllegalStateException("This method should not be called");
   }

The only way to get rid of these methods are to not have the manager class implementing the manager interface though. Although this sounds a bit strange I am sure it can be done but I am equally sure that it is not something that should be given time / energy right now.