Add "generate bibtex from identifier" button in toolbar

[tobiasdiez]

There should be a button in the toolbar which allows to generate a new entry from a given identifier. We could just open the "New entry" dialog on button click, or, what might be more user friendly, open a flyout popup that only contains the lower part of the "New entry" dialog.

Flyout similar to this here:

[chrisjmendoza]

I'm working on this. Already implemented a "New Entry" button next to new article. Working on implementing fly-out.

[atulim]

@chrisjmendoza r u still working on this?

[koppor]

Refs #550

[CarodePourtales]

Hello,
We have to work on an open source project with a group of 6 students for a course in an engineering school and we chose to work on your project. We also choose this issue. Could you gave us further details on what you want ? Thank you a lot !

[tobiasdiez]

@CarodePourtales Thanks for your interest!

The feature should work as follows:

• Add a button in the toolbar
• When the user clicks this button, then a flyout should be displayed with a textbox where the user could insert an ID (DOI, ISBN, ...).
• JabRef then tries to determine the type of the identifier, fetches the corresponding bibliographic information and then creates a new entry with this data.

Implementation wise, the last step is already implemented in https://github.com/JabRef/jabref/blob/master/src/main/java/org/jabref/gui/EntryTypeViewModel.java#L117 apart from the automatic determination of the type of the identifier. Let us know if you need more details and/or if there are still things that are unclear. It would be nice if you could open a pull request very early in your development to outline your ideas and show prototypes.

[CarodePourtales]

Thanks but isn't the issue resolved like the picture shows or do you want something more ?

[tobiasdiez]

Yes, the feature in itself kind of exists. The idea was to move the functionality from the lower part of this dialog to the button in the toolbar. In addition, the ID type combobox should be replaced by an automatic detection of the identifier type (if possible).

So it's a bit of work, but not that involved (depending on how much time you are supposed to invest, it might make sense to look at another issue too).

[koppor]

Please also read along the discussion at #550 (comment). It should provide an idea of the user requirements.

[CarodePourtales]

Hello, I was wondering what a crossref id looks like, because I am using Regex to know what IDBasedFetcher I should use to parse the ID the user enters but I don't know what the user should enter to use a Crossref fetcher.
Thanks

[CarodePourtales]

It looks like that : for Doi, diva and many other fetchers it works because the pattern is very particular and I can use REGEX, but I don't understand Crossref

[CarodePourtales]

I will of course change the look of the string showed but it is just a prototype for the moment

[matthiasgeiger]

👍

Crossref is a fetcher for DOI data (see https://search.crossref.org/)

[github-actions]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!

[tmrd993]

I'd like to play around with this but I don't want to be assigned yet. How would we check if an entered ID is valid? Implement regular expressions for every fetcher? Try every fetcher until a result pops up?

[tobiasdiez]

Nice to hear!

The most versatile approach would be to extend the IdentifierParser by a method that tries to parse the string into one of the Identifier classes. This is a bit similar to the existing

jabref/src/main/java/org/jabref/logic/importer/util/IdentifierParser.java

Lines 25 to 38 in a0284e1

	private static Function<String, Optional<? extends Identifier>> getParserForField(Field field) {
	if (StandardField.DOI.equals(field)) {
	return DOI::parse;
	} else if (StandardField.ISBN.equals(field)) {
	return ISBN::parse;
	} else if (StandardField.EPRINT.equals(field)) {
	return Eprint::build;
	} else if (StandardField.MR_NUMBER.equals(field)) {
	return MathSciNetId::parse;
	}
	// By default, just return empty optional
	return input -> Optional.empty();
	}

, except that we try all parsers and not select one based on a field. Given the parsed identifier, one can then use the following method to get the corresponding fetcher:

jabref/src/main/java/org/jabref/logic/importer/WebFetchers.java

Lines 67 to 74 in a0284e1

	@SuppressWarnings("unchecked")
	public static <T extends Identifier> IdFetcher<T> getIdFetcherForIdentifier(Class<T> clazz) {
	if (clazz == DOI.class) {
	return (IdFetcher<T>) new CrossRef();
	} else {
	throw new IllegalArgumentException("No fetcher found for identifier" + clazz.getCanonicalName());
	}
	}

(As of now this only covers DOIs, but that should be relatively straightforward to extend).

[tmrd993]

I can see that some of the identifier classes have methods that check the validity of the given String id. Shouldn't that be a part of the Identifier interface? Parsing the string into one of the identifier classes would be easier that way. Also, not every fetcher has a corresponding Identifier class as far as I can see. Am I correct in assuming those should be implemented or do they all fall within the available Identifier classes. For example, Crossref and DOI-fetcher both match with the DOI-Identifier but there is no Identifier class for medline or diva.

[tobiasdiez]

have methods that check the validity of the given String id. Shouldn't that be a part of the Identifier interface?

These are static methods, and thus cannot be lifted to the interface. Maybe it would make sense to introduce a IdentifierParser interface in place of Function<String, Optional<? extends Identifier>>?

Also, not every fetcher has a corresponding Identifier class as far as I can see.

Right, that's still work in progress. I would say you can ignore this problem for now and add the button in the toolbar for all fetcher that do have an identifier

[tmrd993]

These are static methods, and thus cannot be lifted to the interface. Maybe it would make sense to introduce a IdentifierParser interface in place of Function<String, Optional<? extends Identifier>>?

Yes, I think that makes sense but there is already a class called IdentifierParser and I'm drawing a blank on what to call that one instead if we are creating an interface with that name. Looking at the class, it seems more like a field parser to me?

[tobiasdiez]

You can rename this class to IdentifierParsers (with s at the end) since it's a factory for the IdentifierParser. We have a similar convention already for WebFetcher(s)

[tmrd993]

Another question, can I use a dialogpane instead of a flyout for now? I'm not seeing a jabref component (or a javafx component) that I can use for that, should that be implemented from scratch? Anyways, I implemented it the same way the new entry view works for a start, by opening a new dialogpane that returns an entrytype. This is what it looks like right now (It also only works for DOI (from CrossRef), Arxiv and ISBN fetchers at the moment as those are the only types that have implemented Identifier classes):

[tobiasdiez]

That looks already pretty nice, thanks for your work!

For the flyout, you can use the popover control. As an example:

jabref/src/main/java/org/jabref/gui/JabRefFrame.java

Lines 941 to 945 in c7f2671

	progressViewPopOver = new PopOver(taskProgressView);
	progressViewPopOver.setTitle(Localization.lang("Background Tasks"));
	progressViewPopOver.setArrowLocation(PopOver.ArrowLocation.RIGHT_TOP);
	progressViewPopOver.setContentNode(taskProgressView);
	progressViewPopOver.show(indicator);

[koppor]

@tmrd993 May I ask for an update? Is there some chance to get this into JabRef?

[koppor]

For the implementation, please also investigate #550. That request asks that JabRef also recognizes 10.1016/j.jrmge.2015.08.004 as DOI and 978-3-86680-192-9 as ISBN.

This issue describes that the lower part of the "new entry" dialog should be duplicated to a toolbar submenu only for an id:

Thus, this is not just a request to add some new dialog, but to work with JavaFX's toolbar magic to create an input possibility directly at a toolbar button.

[tmrd993]

I had stopped working on it because of finals, I'll get back on it if I find the time but I'm not claiming it or anything, if someone else wants to solve this feel free to.

[tmrd993]

This issue describes that the lower part of the "new entry" dialog should be duplicated to a toolbar submenu only for an id:

Thus, this is not just a request to add some new dialog, but to work with JavaFX's toolbar magic to create an input possibility directly at a toolbar button.

I'm not sure I understand the requirements, is it supposed to be a Menu object inside the toolbar that opens up a text input for the id? Is there some graphical example of this?

This is how I pictured it:

[koppor]

Looks good. The implementation should try different Ids and try to fetch it. --> The user should not be required to input the Id type. Only the Id (as you shown it). (This is #550)

The position should be below the button (as I interpret your screenshot)

[Siedlerchr]

Thanks to @colinhex the feature is now implemented!