Comment 30 for bug 1251394

I don't see a problem with the template's conception of field names being required to match extant CMF rows. We're effectively doing that by hard coding xpath to extract fields now in any case.

[thinking...] Extending the representative field concept to point through a new table mapping from the display field controlled-names to actual fields (a la config.metabib_search_alias) seems perfectly doable to me. IOW, we put a table between config.metabib_class.representative_field and CMF that looks like:

CREATE TABLE config.display_field_map (
  id serial,
  name text,
  cmf int references config.metabib_field (id),
  multi bool default false
);

The templates would reference config.display_field_map.name, we would construct a "display fields" object with config.display_field_map.name as the keys, and values of, perhaps, serialized json containing a scalar where config.display_field_map.multi is false or an array where it's true. That can, at the SQL level, be of type JSON (available in future-required PG versions) and built with JSON contruction functions, also available. Templates would just JSON.parse() (in angular interfaces that use pcrud) or JSON2perl() (in OPAC-style templates) to reconstitute the data.

In fact, we could use a view over metabib.display_field_entry to construct these objects for use by both the templates (they fetch directly by record id), and the simple-record view which can simply de-JSON-ify each field in a predictable way by looking at the mapping table (bonus: including nicer formatting that removes the {}s on arrays).

The first view would be a 3-column view (record id, field name, json data) and the simple-record view would pivot specific rows from that to a wide projection with prescribed columns.

This provides us vocab control, programmatic mapping, and backward compatibility, I think...

With that, I don't see a good argument for creating a new display class -- we have the catch-all keyword class, and can just map through to that.

Thoughts?