Re: [Cdk-devel] DescriptorEngine questions

[Rajarshi G. <raj...@gm...>]

On Thu, 2006-07-06 at 17:36 +0300, Nina Jeliazkova wrote:
> Hi,
> 
> Rajarshi Guha <raj...@gm...> wrote:
> 
> > 
> > But then the problem is: if we want to continue with the rest of the
> > descriptors we have to maintain a list of exceptions thrown and which
> > descriptor/molecule they were thrown for. This becomes a little messy.

> 
> Another suggestion: continue with for loop, but define something like
> exception handler in DescriptorEngine and then just invoke it in case of
> exception
> 
> <code>
> for (int i = 0; i < descriptors.size(); i++) {
>         	IDescriptor descriptor = (IDescriptor)descriptors.get(i);
> try {
> } catch (CDKException exception) {
>    handleException(x)
> }
> 
> ....
> 
> procedure void handleException(CDKException x) {
> //some default behaviour - logging or even throwing exception as now
> }
> 
> </code>
> 
> Then a freakish user can subclass (!) DescriptorEngine and define his own
> handler. Does it make sense?


This would work - however rather than subclassing why not just have
DescriptorEngine have a field which would be, say, a
DescriptorEngineErrorHandler object, with a well defined interface.

This might be more work, but maybe more well defined? I'm not sure.
Subclassing seems to be the easy way out :)

> Well, my intention was to add some descriptors, that do not belong to
> org.openscience.cdk.qsar.descriptors.molecular
> but still implement IMolecularDescriptor. That seems not possible now (or I am
> unable to figure out how to do it). 

Write your descriptors. Make sure they are in one of the following
packages:

org.openscience.cdk.qsar.descriptors.atomic
org.openscience.cdk.qsar.descriptors.bond
org.openscience.cdk.qsar.descriptors.molecular

jar up your descriptors and add it to the system classpath. The engine
should find them. (at least this was the intention when I wrote the code
- but I never really tested it!)

I realize that forcing users to place their own descriptors in the above
packages is not optimal. Ideally I would inspect each descriptor to see
which interface it implements. But that would require instantiation of
all the classes I find in the classpath which is not a good idea.

The other alternative which is doable is to have a plugin list stored in
a file. The default file would be in the CDK jars and simply list which
descriptor class belongs to which group. I could add a constructor that
would take in a user specified plugin file (in addition to the CDK one)
and load the classes specified in the plugin list.

A basic format would be

<plugins source="CDK">
<descriptorType type="molecular">
 <descriptor className = " .... " />
 <descriptor className = " .... " />
</descriptorType>
....
</plugins>


-------------------------------------------------------------------
Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net>
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
-------------------------------------------------------------------

Q: What is a dyslexic, agnostic, insomniac?
A: Someone who lays awake at night wondering if there really is a dog!