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

[WIP] Prototype for new EntryType interface #501

Closed
wants to merge 1 commit into from

Conversation

tobiasdiez
Copy link
Member

This is a prototype for an idea to resolve the issues discussed in #337 and #495.

Right now the entry type is converted from a string representation (in the bibtex file) to an EntryType by the parser. The problem with this approach is that the parser has to know about the bibtex vs biblatex mode. The idea was to add an intermediate step:
String (in Bibtex file) -> EntryClass (by parser) -> EntryType (by some factory using information from the preferences)

  • There is an enum StandardEntryClass holding all the standard types regardless of bibtex or biblatex (so article, mvbook, etc, all are there). To support also unknown entry types we have the class NonStandardEntryClass. So for example, parsing @article{} results in class = StandardEntryClass.ARTICLE while @gibberish{} yields class = NonStandardEntryClass with name gibberish. In this way the type information is stored in a relative convenient form (better then a string).

The idea of an enum implementing an interface was taken from the way java handles standard file locations. See the oracle blog (or another blog).

  • The EntryClass does not know about required and optional fields. These information are provided by the EntryTypeFactory. For example, entryTypeFactory(prefs).getTypeFor(StandardEntryClass.ARTICLE).getRequiredFields() gives the required fields.

Please ignore all the "my" prefixes in the class names.

@tobiasdiez tobiasdiez changed the title Prototype for new EntryType interface [WIP] Prototype for new EntryType interface Dec 10, 2015
@tobiasdiez
Copy link
Member Author

So, what are your opinions on this idea? Should I start implementing it properly or is there a better way to solve this issue?

@tobiasdiez
Copy link
Member Author

New and simpler solution can be found in PR #605.

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.

1 participant