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 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.