[referencer] dealing with different entry field requirements

[jcspray at icculus.org]

Quoting Davyd Madeley <davyd at madeley.id.au>:

> Maybe this is a bit crack and maybe I should cut some `sed` to fix this,
> but I was wondering if there were any ideas to address the requirement
> that different entry types (eg. Article, InProceedings, etc) require
> different fields populated (at least this is the case for the IEEEtrans
> stylesheet).

(Aside: one of the headaches with this is that referencer isn't  
intended to be bibtex-specific.  Any code changes to accomodate  
bibtex-isms have to be general enough for other formats too, or at  
least allow for at some point in the future having a "Bibtex mode" an  
"OpenOffice mode" etc.  Notable sinful exception to this is the  
current hard-coded list of document types).

There are a few ways to approach this:
  1. The "if you want anything but article you're on your own"  
approach (the way referencer is).
  2. Adding the appropriate custom fields when the user selects a  
different document type, so they're still getting 2nd class UI, but at  
least the user doesn't have to know the bibtex to type in.
  3. A fully dynamic UI, in which fields appear and disappear  
according to which document type is selected, and there's some  
indication of which fields are mandatory and which are optional.

Obviously option 1 sucks.  It's the current state because referencer  
was developed with very limited resources to provide a good solution  
for managing papers.  This is often an irritating shortcoming: in my  
own work, I often encounter InProceedings documents, and I realise  
that many other people would like books in particular to be better  
supported.

Option 2 would be pretty straightforward to implement, and I would be  
receptive to a patch which implemented it.  One would need to:
  - Compose a lookup table of which extra fields are needed for which  
document type.
  - When the user changes document type in the document properties  
dialog, add any needed custom fields AND remove any which are  
redundant iff they haven't had values set.
  - Make sure the extra fields area was shown and hidden appropriately  
as fields are added and removed.

For clarity, I would suggest only automatically adding the mandatory  
fields -- the list of all optional fields can get a bit long for some  
types, and is confusing for someone who's not a bibtex afficionado.

Option 3 is what a number of other programs do, and it's very helpful  
for maximising the distance between the user and the raw bibtex.  On  
the other hand, it involves widgets magically appearing and  
disappearing, which is a bit evil from an elegant-UI point of view.   
Also, when all the optional fields are shown, the dialog could get  
pretty huge, and might require some rearranging.

To do this kind of full-on bibtex smartness, some code would need  
reworking outside of the document properties UI: rather than the  
current BibData structure which has hard-coded members for title,  
author etc, one would need a generalised list of fields.  I'm open the  
criticism that it should have been this way to begin with: in my  
defense I started a lot of that code on a train out of boredom, with  
no intention of it ever being release-worthy :-)

> The most common one appears to be journal vs booktitle, so at the moment
> I'm going through and adding the custom field of booktitle as
> appropriate, but I've been wondering if there would be a more sensible
> way to fix this in referencer. Then I got to wondering if different
> stylesheets have different required fields, and how quickly this could
> all go down hill.

In my experience bibtex is pretty liberal about which fields you  
include -- it tends to silently ignore (or sometimes include) fields  
which are in theory not available for a given document type.  As for  
different styles having different requirements, I don't know -- it  
would be a huge pain if that was the case.  Hopefully it's not the case.

John