Add NameService and NameProvider
This allows to define a way to derive names from objects of third party libraries, e.g. for use in ObjectService, where objects are registered with a name and can be provided e.g. in a drop-down choice in the UI.
This pull request, together with https://github.com/imagej/imagej-legacy/pull/263, will resolve this forum discussion about being able to automatically populate ij.measure.ResultsTable inputs, provided we implement the following ResultsTableNameProvider in a follow-up pull request to imagej-legacy:
package net.imagej.legacy.plugin;
import org.scijava.names.NameProvider;
import org.scijava.plugin.AbstractHandlerPlugin;
import org.scijava.plugin.Plugin;
import ij.measure.ResultsTable;
@Plugin(type=NameProvider.class)
public class ResultsTableNameProvider extends AbstractHandlerPlugin<Object> implements NameProvider {
@Override
public String getName(Object thing) {
return ((ResultsTable) thing).getTitle();
}
@Override
public boolean supports(Object thing) {
return ResultsTable.class.isAssignableFrom(thing.getClass());
}
}
(Suggestions welcome to make this even more concise!)
Hi @imagejan ,
Could this provide a mechanism to solve https://github.com/imagej/imagej-legacy/pull/243 as well ?
@NicoKiaru absolutely, it could solve the problem of having Pet@57a3e26a instead of Felix as a name in your example. In general, this allows giving names to any object of a third-party library (i.e. not under your control) by adding a NameProvider plugin that can be discovered at runtime.
Then it could be adde in the ij1 macro engine I guess ?
https://github.com/imagej/imagej-legacy/blob/5c46549e765b3148d767a8c90d15b6be03b4c154/src/main/java/net/imagej/legacy/plugin/IJ1MacroEngine.java#L251
@NicoKiaru iff the change proposed here gets merged and included in a release, and then the change from v.toString() to objectService.getName(v) you proposed in https://github.com/imagej/imagej-legacy/pull/243/files#diff-de04251535e202b6132a0485276551de8ec4b1e86a639a9b54c67d63527ef5e1R251 is indeed sufficient to have the desired recording behavior (for objects where you also implement a NameProvider).
The remaining issue would then be the other direction, determining the object from the given name, which is potentially ambiguous, but let's discuss this on the imagej-legacy issue.
The remaining issue would then be the other direction, determining the object from the given name, which is potentially ambiguous
Getting a converter from String to an object can be handled quite correctly by converter I find, but ok, let's keep this as a discussion in imagej-legacy.
For this PR, I have a question regarding the following use case:
Imagine you have 5 different objects in the object service of a certain class Image. Would the mechanism you suggest assign a name to an array of such objects ? This could be convenient for an Image[] input parameter for instance.
If yes, could we make this modular ? Like can Object in your example, be of class Image[] ?