vegard nygaard wrote:
> Hi.
> I have now modified my BASE2.4 code to the "Abstract" version, laid out
> earlier by Nicklas. I got it to work and it will do very well for my needs,
> that is if I understood what the plan really was. It would be nice if Lund
> put it into the next version. But verify that this was what you meant and
> modify it to fit your coding practice. And others might want different
> things done.

Thanks for the code. I appreciate your effort, but I don't think it will 
be very useful for us (or anybody else).

As far as I can tell the only real changes was to add the 
initBioAssaySetExporter() and exportBaseFileSectionNonStandard()
methods. All other existing methods are still private and will not be 
available to subclasses for other developers.

Moving the code from one class to another was what I meant. I think it 
requires a bit more hard work to decide what should go where and what 
should be public/protected/private.

The AbstractPluginExecuter could, for example, be an abstract base class
for all plug-ins with an execution pattern like this:

1. export data
2. start an external program that processes the data
3. import new data generated by the external program

The actual format of exported/imported data should then go into the
non-abstract subclasses. In this case, the Base1PluginExecuter exports a
BASEFile (with the help of the BioAssaySetExporter), and imports
BASEFile:s and other files. This is only one example of how it could be
done.

The first thing to do is to come up with and agree on a
specification/design of the abstract classes. Maybe use the current
plug-ins as a test bed for a simple prototype. Then, when everything
seems to be working the "real" coding can begin. This is not a
high-priority issue for us, so it would be great if we get help with 
specification, design and implementation.

Since your changes are rather small another solution in your case is to 
keep a locally modified copy of BASE. If you do a subversion checkout 
your changes will be merged automatically when you do 'svn update' to 
get the a new version. The only thing to keep in mind is to only install 
released versions. Using the latest trunk will be too unstable. This 
should get you going until something better has been developed.

A third option is to create non-plugin classes for reading and writing
BASEFile:s, for example, BaseFileReader and BaseFileWriter. This is in
the direction of separating functionality as suggested earlier by
Gregory. If done right, the plug-in code will be much simplier, for example:

writer = new BaseFileWriter();
writer.section("assay2rawdataset");
writer.header("columns", "id", "rawdataset");
...
writer.data(ba.getId(), rawBioAssayIds[0]);
...

The writer/reader could also contain higher-level methods:

...
writer.writeSectionSpots(BioAssaySet, .... and a lot more parameters)
...

/Nicklas


> This is what I did.
> Made an AbstractBase1PluginExecuter that is almost the same as the old
> Base1PluginExecuter
> Modified Base1PluginExecuter so that it just contains what differs from my
> version
> Made VegardsBase1PluginExecuter; my version not to be included in a the Lund
> code. Just to show what I needed.
> 
> Made an AbstractBioAssaySetExporter that is almost the same as the old
> BioAssaySetExporter
> Modified BioAssaySetExporter so it contains nothing.
> Made VegardsBioAssaySetExporter; my version not to be included in the Lund
> code. Just to show what I needed and not finished.
 >
> Actually for my use, I did not have to abstract the BioAssaySetExporter,
> since it does nothing more that the abstract class. It is only my version
> that does a add-on. I abstracted it anyway in order to be compliant.
> 
> The actual code change I did in the abstract classes was to isolate the
> change I needed and make a method that could be overridden by my class and
> others. I hope this was allowed or else I am in trouble.
> 
> I don't think it works with attachments in this mailing list and I don't
> think I have any rights in the subversion to upload my code so I provide my
> files here:
> http://insilico.titan.uio.no/~vegardny/base2/VegardsBase1PluginExecuterModification.zip



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
basedb-devel mailing list
basedb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/basedb-devel

Reply via email to