search

scijava / scijava-common

A plugin framework and application container with built-in extensibility mechanism :electric_plug:
BSD 2-Clause "Simplified" License
91 stars 52 forks source link

should we have a converter preprocessor? #189

Open hinerm opened 9 years ago

hinerm commented 9 years ago

in imagej-matlab we have to create a custom Preprocessor to ensure the Converters are actually used in scripts, converting datasets to numeric arrays.

@bnorthan basically had to copy this logic for ITK-ImageJ converters. This is kind of unintuitive so maybe we should have a general input preprocessor that tests for potential conversion opportunities

We could specialize this, i.e. perhaps the Dataset preprocessor should always claim inputs if it can convert datasets to the requested type?

hinerm commented 9 years ago

@ctrueden you know best here how this behavior could be slotted in...

I'm partial to a Dataset preprocessor just leveraging the ConvertService

hinerm commented 9 years ago

in which case this would go in imagej-common

ctrueden commented 9 years ago

I gave this a bit of thought. The typing is a little tricky.

Suppose your command declares the following parameters: Foo foo, Bar bar, and SpecialFoo specialFoo (extends Foo). And suppose you also wrote DatasetToFooConverter and DatasetToBarConverter.

Now, in that scenario: should each of the foo, bar and specialFoo parameters each be filled with a converted version of the active Dataset?

Let's assume the answer is yes, and go from there. Now we want to generalize the ActiveDatasetPreprocessor to not only look for single Dataset inputs, but also single inputs of any type which can be converted from Dataset. The ConvertService makes the latter question easy to answer, but the former question requires some more groundwork because the current SingleInputPreprocessor is very much focused on limiting the parameter search by type. Ultimately it leans on the getSingleInput method of ModuleService, which is also type-centric.

So I think we would need to reconsider exactly how "single inputs" are determined in order to address this feature request...