Field properties - future implementation

[oscargus]

Based on some earlier discussions, e.g., koppor#59 #967 koppor#32 , it seems to make sense to redefine and restructure the properties of each field. At the moment it is handled by https://github.com/JabRef/jabref/blob/master/src/main/java/net/sf/jabref/gui/InternalBibtexFields.java and especially the class BibtexSingleField in that file.

Currently the following properties are defined:

• final String name; - the name of the field
• int flag - a combination of

        private static final int STANDARD = 0x01; // it is a standard bibtex-field
        private static final int PRIVATE = 0x02; // internal use, e.g. owner, timestamp
        private static final int DISPLAYABLE = 0x04; // These fields cannot be shown inside the source editor panel
        private static final int WRITEABLE = 0x08; // These fields will not be saved to the .bib file.

• int length - field length in characters(?)
• double weight - weight factor used for relative row size in the entry editor columns(?)
• int editorType - may be one of

    // constants for editor types:
    public static final int STANDARD_EDITOR = 1;
    public static final int FILE_LIST_EDITOR = 2;

• String extras; - Determines any extra component in the entry editor, currently one of:

    public static final String EXTRA_YES_NO = "yesNo"; // Blank/Yes/No Combo-box
    public static final String EXTRA_URL = "url"; // Drop target for URL
    public static final String EXTRA_DATEPICKER = "datepicker"; // Calendar button and double-click in field to set current date
    public static final String EXTRA_JOURNAL_NAMES = "journalNames"; // Journal abbreviation button
    public static final String EXTRA_EXTERNAL = "external"; // Open external viewer on double-click
    public static final String EXTRA_BROWSE = "browse"; // Browse button, file dialog
    public static final String EXTRA_SET_OWNER = "setOwner"; // Button to set owner to current used
    public static final String EXTRA_MONTH = "month"; // Button to show the months and set abbreviation

• boolean numeric; - true if the field is expected to be numeric and in that way one can sort based on that

My idea is to extend this. Currently, there are quite a lot of different fields, especially in Biblatex that has the "same" properties. For example, there are about ten or so different fields with names defined and it would be much better if one could check field.isNameField() instead of comparing against all the possible field names (now, mainly author and editor is checked). This would be useful for e.g. the integrity checks. Similarly, it would make sense if the field knew how it should be sorted (e.g. the date field in biblatex could use a dedicated comparator). Also, some fields can only take on specific values, either from a list (like month or languague) or being a number, like year. From a layout perspective, it is discussed in #967 that different fields should have minimum/maximum sizes and that some benefit from resizing, some not. Add to that alignment and the size required in the entry editor.

The purpose of this issue is to try to come up with a good redesign of BibtexSingleField. It appears to me as there are a few larger problems here:

1. Which properties should be included?
2. How is this mapped in practice from fieldname to property? Probably one should refactor and move this to logic as some methods in logic right now tests for fieldname.
3. How should they be set (and saved) in practice? Like today, but extended? Would somehow be nicer if each type (or class of types) has the default knowledge.
4. What about defining custom fields?
5. Is this saved per database or in the preferences?

To this end, I'd suggest the following fields:

• String name
• int flag - as before
• int type - Combination of the following constants (numerical value tbd, probably more are needed, the Biblatex manual decribes this pretty well)
  • namelist - for author names - gives the field editor button and triggers "correct" integrity checkers
  • keyword - field editor, can be set for other fields as well (which some people appears to be using)
  • journal - journal list/abbreviation
  • title - integrity check
  • date - date picker, special sorter, integrity check
  • month - month list, integrity check (number in Biblatex)
  • integer - numerical sorting, only numerical value(?) (used for e.g. year, maybe number and volume, some IEEE fields)
  • pagerange - integrity checker
  • file - file-field parsing
  • yesno - IEEE yes/no
  • language - select among languages (is a list)
  • pagination - list of pagination alternatives
  • editortype - list of editor type alternatives
  • texcode - probably warn if one runs latex to unicode conversion on this field...
  • uri - droptarget for URL, possibility to open URL
  • doi - special handling and checking
  • owner - set owner on double-click
  • crossref - must be a bibtexkey
  • gender - list of alternatives
  • options - key=value pairs
  • related - bibtexkeys (not what is sometimes discussed as "referenced by" etc)
  • relatedtype - list of options (see Biblatex documentation)

Entry editor related

• double weight - as before

Main table related

• boolean resizable
• int minimalSize
• int maximalSize
• LayoutFormatter layoutFormatter - should a layoutformatter be used for the field and in that case which(?)
• boolean resolve - should the field be resolved for strings(?)
• Comparator comparator ? or handle by type?
• int alignment - one of left, right, center (are there use cases for center? Numbers should probably be right-aligned anyway)

[Siedlerchr]

First of all I suggest to use Enums with EnumSets instead of the int-Flags:
See http://eddmann.com/posts/using-bit-flags-and-enumsets-in-java/

From my perspective I would be in favor of separating gui and logic, and not store the mainTable sizes in the internal fields.

[simonharrer]

We want to get rid of these flags anyway. There is an issue around, but I cannot find it right now. Maybe @koppor can help.

[oscargus]

#650 ? Get rid of them totally? Not sure that I follow here, but wouldn't it make sense to keep all field-related information in one place?

@Siedlerchr Maybe not the actual sizes, but the behavior of the field. To me it makes sense to keep all information/properties related to fields in a single place. EnumSet seems like what I was looking for.

[oscargus]

After reading up on biblatex a bit more there are special fields for sorting. Would it make sense to include that here as well? A field which if non-empty points to another field to be used for sorting? (With the Biblatex mapping set by default.)

[koppor]

The argumentation is given at #850: int flag has to be removed.

[simonharrer]

On what feedback are we waiting here?

[koppor]

Shouldn't type be mutually exclusive?

[oscargus]

@simonharrer : good question. I remove the tag. There is still some feedback related to the MainTable stuff required though.

@koppor: maybe. The reason that it wasn't stated originally was e.g. numeric sorting. Either one use a separate flag for that or add it as a type. I would assume that there are some other properties which may be similar when considering e.g. checkers. An alternative would of course be to have a mutually exclusive type and then some properties field.

[koppor]

Although currently none of us has time to work on it, I just wanted to reference the issue discussing the flag field: #574

[tobiasdiez]

I recently had a look at this class and, although not perfect, the code is now in a reasonable good state. There is still some gui-related stuff hidden in this model class, which should be removed at some point, but I don't think we should keep an issue just for this.

Thus closed...