Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move labelpattern #1626

Merged
merged 11 commits into from
Aug 9, 2016
Merged

Move labelpattern #1626

merged 11 commits into from
Aug 9, 2016

Conversation

lenhard
Copy link
Member

@lenhard lenhard commented Jul 25, 2016

Minor refactoring and moving of classes from logic into model. The XXXLabelPattern classes really describe how we serialize and store label patterns (part of the structure of meta data). Hence, they belong into model and have already been almost independent of other classes. The util class with helpful functions regarding label patterns can stay in util.

@lenhard lenhard added component: cleanup-ops status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers architecture labels Jul 25, 2016
}

public static void updateDefaultPattern() {
defaultLabelPattern = AbstractLabelPattern.split(JabRefPreferences.getInstance().get(JabRefPreferences.DEFAULT_LABEL_PATTERN));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of relying on the preferences within this class, could the preference value just be passed through a parameter? Then this class would be independent of the preferences package.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #1607. :-) Not sure what is the best merging order...

Copy link
Member Author

@lenhard lenhard Jul 25, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@simonharrer Good idea
@oscargus Oh no, now I have already rewritten GlobalLabelPattern :-(

However, it seems you did not really touch the class in #1607? From what I have seen and tested with the GUI, you can completely drop the static part of GlobalLabelPattern. It is just initialized in two places (the gui and the preferences) and both of these places have access to the gui, so you can provide the correct parameters right away.

Regarding merging order: I'd prefer mine to be merged first :P Anyway, let Simon decide!

@simonharrer
Copy link
Contributor

LGTM

@oscargus how does this affect #1607 ?

@oscargus
Copy link
Contributor

No idea. Probably a bit of resolving independent of who merges first. The feeling is that it is easier to merge the PR without moving of files first, but I'm not sure if that is true or if I just want less work. ;-)

@oscargus
Copy link
Contributor

oscargus commented Jul 25, 2016

By the way, there is a preference setting "Enforce legal characters in BibTeX keys". Is that really needed?

The difference is the characters in "{}(),\\\"#~^'" but not in "{}(),\\\"" so "#~^'". I'm wondering if we upset many people by always enforcing legal characters?

@lenhard
Copy link
Member Author

lenhard commented Jul 26, 2016

@oscargus: My changes were quite small and would be relatively easy to redo, so it's ok for me if you go first.

Regarding the BibTex keys: We have already upset at least one person in #1272. We talked about this issue on the devcall right now and arrived at the following decision:

  • The preference setting "Enforce legal characters in BibTeX keys" can be removed, hence we will only enforce "{}(),\\\"#~^'".
  • Key validation should be based on the mode (BibTeX, BibLaTeX). Especially BibLaTeX is more strict and there should be an additional validation that checks for the symbols that are not allowed in BibLaTeX

@oscargus
Copy link
Contributor

OK! If anyone could have a look at the PR I'll merge it.

So basically, the (in the PR introduced) boolean argument to checkLegalKey should be replaced with isBibLatex? Is it clear what the set of symbols are for the two cases?

@tobiasdiez
Copy link
Member

And we considered moving the check to the integrity dialog.

# Conflicts:
#	src/main/java/net/sf/jabref/gui/preftabs/LabelPatternPrefTab.java
#	src/main/java/net/sf/jabref/logic/labelpattern/LabelPatternUtil.java
#	src/main/java/net/sf/jabref/preferences/JabRefPreferences.java
@lenhard
Copy link
Member Author

lenhard commented Jul 28, 2016

Should be good to go.

Just as a side note: What are the "default" buttons in Preferences-> BibTeX key generator supposed to do? For me, only the button for the default pattern works and actually resets something. The other default buttons basically just delete what I have entered into the corresponding text field. This behavior is independent of this PR.

@oscargus
Copy link
Contributor

I think the default is that every type has the same key pattern, so it makes sense that the pattern is cleared when clicking Default.

@oscargus
Copy link
Contributor

LGTM! 👍

@matthiasgeiger
Copy link
Member

I'm not sure whether we discussed it in this context at the last devcall, but moving those classes will lead to another node in the registry for storing those preferences - if the storing mechanism is not adjusted.

@lenhard
Copy link
Member Author

lenhard commented Jul 28, 2016

@matthiasgeiger: Are you sure? Didn't that already happen through #1635 by introducing the new LabelPatternPreferences? As far as I understand, the old label preferences get lost through this change, but will not so easily get lost in the future, since they are now normal preferences.

@matthiasgeiger
Copy link
Member

Just tested it: v3.5 and current master reads and writes from/to HKEY_CURRENT_USER\SOFTWARE\JavaSoft\Prefs\net\sf\jabref\logic\labelpattern - your branch reads and writes from/to HKEY_CURRENT_USER\SOFTWARE\JavaSoft\Prefs\net\sf\jabref\model\labelpattern

@matthiasgeiger
Copy link
Member

matthiasgeiger commented Jul 28, 2016

@lenhard
Copy link
Member Author

lenhard commented Jul 28, 2016

Migrations are overrated :-)

We should at least change that to

Preferences pre = Preferences.userNodeForPackage(JabRefMain.class);

to avoid future issues.

Although not part of this PR, let us keep this open and discuss at the next devcall on how to proceed.

Refs: #1257

@matthiasgeiger
Copy link
Member

Another topic for the devcall: Can we rename this "LabelPattern..." stuff to "BibtexKeyPattern..." ? - I never understood why this is called "label pattern" 😉

@oscargus oscargus mentioned this pull request Jul 28, 2016
@tobiasdiez tobiasdiez added the dev: code-quality Issues related to code or architecture decisions label Aug 4, 2016
@lenhard
Copy link
Member Author

lenhard commented Aug 9, 2016

TODO in new PR after this one is merged:

  • Integrate label pattern preferences tree into global preferences tree
  • Rename label pattern to bibtex key pattern.
  • Possible migration of old key patterns

lenhard added 3 commits August 9, 2016 14:12
Conflicts:
	src/main/java/net/sf/jabref/JabRefMain.java
Conflicts:
	src/main/java/net/sf/jabref/MetaData.java
@lenhard lenhard merged commit c004550 into master Aug 9, 2016
@lenhard lenhard deleted the move-labelpattern branch August 9, 2016 12:39
Siedlerchr added a commit to Siedlerchr/jabref that referenced this pull request Aug 9, 2016
* master: (22 commits)
  Do not cite entries without a key in OpenOffice/LibreOffice (JabRef#1682) (JabRef#1683)
  Got rid of unused preferences (JabRef#1672)
  Move labelpattern (JabRef#1626)
  Implementation of shared database support (full system). (JabRef#1451)
  Removed bst from architecture tests JabRef#1699
  Update PULL_REQUEST_TEMPLATE.md
  French localization: Menu: Translation of an empty string
  French localization: Jabref_fr: empty strings translated
  Updated string similarity version (JabRef#1698)
  Minify description of release process
  Announce switch from GPL to MIT in CONTRIBUTING.md and README.md
  Some cleanups to initialize empty MetaData at fewer positions (JabRef#1696)
  Automatic group names are converted from LaTeX to Unicode (JabRef#1684)
  Update ISSUE_TEMPLATE.md (JabRef#1686)
  Removed (false) NPE issue reported by FindBugs
  More Swedish translations (JabRef#1691)
  Updated wiremock version (JabRef#1690)
  Some minor code cleanups (JabRef#1689)
  Removed dependencies of Globals.prefs in some tests (JabRef#1688)
  Lookup BibEntry from ISBN and merge information (JabRef#1621)
  ...

# Conflicts:
#	src/main/java/net/sf/jabref/gui/BasePanel.java
#	src/main/java/net/sf/jabref/importer/ImportMenuItem.java
#	src/main/resources/l10n/JabRef_da.properties
#	src/main/resources/l10n/JabRef_de.properties
#	src/main/resources/l10n/JabRef_en.properties
#	src/main/resources/l10n/JabRef_es.properties
#	src/main/resources/l10n/JabRef_fa.properties
#	src/main/resources/l10n/JabRef_fr.properties
#	src/main/resources/l10n/JabRef_in.properties
#	src/main/resources/l10n/JabRef_it.properties
#	src/main/resources/l10n/JabRef_ja.properties
#	src/main/resources/l10n/JabRef_nl.properties
#	src/main/resources/l10n/JabRef_no.properties
#	src/main/resources/l10n/JabRef_pt_BR.properties
#	src/main/resources/l10n/JabRef_ru.properties
#	src/main/resources/l10n/JabRef_sv.properties
#	src/main/resources/l10n/JabRef_tr.properties
#	src/main/resources/l10n/JabRef_vi.properties
#	src/main/resources/l10n/JabRef_zh.properties
ayanai1 pushed a commit to ayanai1/jabref that referenced this pull request Sep 5, 2016
* Move classes describing the structure of label patterns into model

* Remove unnecessar import

* Fix checkstyle errors

* Fix checkstyle errors in tests

* Rewrite GlobalLabelPattern and remove static parts

* Fix checkstyle error: The intellij checkstyle plugin and me will never be friends

* Add getter for default label pattern

* Remove unused imports
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dev: code-quality Issues related to code or architecture decisions status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants