← 返回首页
Add NameService and NameProvider by imagejan · Pull Request #425 · scijava/scijava-common · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Resetting focus

Add NameService and NameProvider#425

Open
imagejan wants to merge 1 commit into
masterfrom
nameservice
Open

Add NameService and NameProvider#425
imagejan wants to merge 1 commit into
masterfrom
nameservice

Conversation

Copy link
Copy Markdown
Member

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 imagej/imagej-legacy#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!)

This change 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.
imagejan requested a review from ctrueden June 22, 2021 18:55
Copy link
Copy Markdown
Contributor

Hi @imagejan ,

Could this provide a mechanism to solve imagej/imagej-legacy#243 as well ?

Copy link
Copy Markdown
Member Author

@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.

Copy link
Copy Markdown
Contributor

Copy link
Copy Markdown
Member Author

@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.

Copy link
Copy Markdown
Contributor

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[] ?

ctrueden self-assigned this May 3, 2023
ctrueden force-pushed the master branch 3 times, most recently from 53b6733 to 3dc99c9 Compare November 7, 2023 18:37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Footer

© 2026 GitHub, Inc.