Comment 37 for bug 1251394

After experimenting and sleeping on this a bit, I have some thoughts.

Adding the new config.display_field_map table means also adding code/documentation for a new interface to manage the table. It also means staff have to visit two UI's to add a new display field. The new table only gives us one column: multi. (It also gives us a 'name' column, but that's not strictly necessary -- more below). This seems like a lot for one column.

I'd like to revisit Galen's suggestion of adding a new "display" metabib class. I see a few benefits to this:

1. It creates a clear separation between display fields and index, etc. fields. I think in practice, few metabib_field's would be both a display and index field and separating them from the start will make them easier to manage and faster to re-ingest for display-only ingests.

2. We can use the config.metabib_field.name column however we need to support named fields, since the unique restriction on names is per-metabib class. I.e. we don't need config.display_field_map.name.

3. No new config.display_field_map table would be required, so no new interface is required. We can add a new display_multi:bool field to config.metabib_field and drop the 2 new display_field and display_xpath fields, since they will be covered by metabib_class='display' and the existing 'xpath' column.

My only concern is whether adding a new metabib class (which we rarely do) will have unexpected consequences in the code.

Thoughts appreciated.