search

komalsahedani / cleartk

Automatically exported from code.google.com/p/cleartk
0 stars 0 forks source link

Eliminate CleartkMultiDataWriterFactory and CleartkMultiClassifierFactory #325

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I have been re-examing Issue 248 in light of the changes to CleartkAnnotator 
that added a defaultDataWriterFactory.  This change greatly improved the 
usability of CleartkAnnotator.  Now for CleartkMultiAnnotator, I'm wondering if 
it is necessary to have extra CleartkMultiDataWriterFactory and 
CleartkMultiClassifierFactory interfaces.  The interfaces only add a name 
paramater to createDataWriter() and createClassifier() methods, and otherwise 
the implementations just act as wrappers for their non-multi companions.

It seems that in practice the only use of this extra name parameter is to 
append onto the outputDirectory or jar model Directory before a a subsequent 
call to the delegated DataWriterFactory or ClassifierFactory.  Admittedly, one 
can image a more complex use case where the name is needed for much more, but 
realistically nearly all of the same behavior could be achieved by making a new 
DataWriter/Classifier Factory with an additional name configuration parameter.

So here is what I'm proposing to fix this bug and streamline the CleartkMulti* 
experience:
1) Eliminate CleartkMultiDataWriterFacotry and CleartkMultiClassifierFactory
2) The getDataWriter(name) and getClassifierMethods(name) in 
CleartkMultiAnnotator will now call the dataWriterFactory / classifierFactory 
directly instead of delegating the task to CleartkMulti*Factory.  This also 
means CleartkMultiAnnotator is also responsible for reinitializing outputDir 
and modelDir config parameters.  (as an added bonus this fixes issue #248.

I think this should would be the 80% solution for most use cases and would 
reduce complexity in an already clunky Multi* api.

Original issue reported on code.google.com by lee.becker on 5 Aug 2012 at 4:54

GoogleCodeExporter commented 9 years ago 
Correction I mean Issue 252 not 248.

Original comment by lee.becker on 5 Aug 2012 at 4:54

GoogleCodeExporter commented 9 years ago 
Yep, this is exactly what I had in mind for Issue 252. Please go ahead with it.

Original comment by steven.b...@gmail.com on 5 Aug 2012 at 5:40

GoogleCodeExporter commented 9 years ago 
Fixed in r3968.

Original comment by lee.becker on 6 Aug 2012 at 7:36