Hey Mike, I think this sounds good. This gets us all the way back, as alluded, to a reporter.simple_record replacement.
Am I right to assume the 3-column view could contain both controlled fields plus any locally added custom fields, while the simple-record view would only include the controlled fields (a la reporter.simple_record)? That is, unless someone locally modified the view and its IDL class.
And of course we no longer need the representative_field column now, since the purpose of each field will be implicit in its name.
For the 3-column view, it sounds like we're essentially morphing the "mfde" IDL (view) class from the working branch, teaching it to understand config.display_field_map / multi, to JSON-ify the data, and to drop a few unneeded fields. And I assume the "name" column would be config.display_field_map.name, which we'll require to be unique.
Hey Mike, I think this sounds good. This gets us all the way back, as alluded, to a reporter. simple_ record replacement.
Am I right to assume the 3-column view could contain both controlled fields plus any locally added custom fields, while the simple-record view would only include the controlled fields (a la reporter. simple_ record) ? That is, unless someone locally modified the view and its IDL class.
And of course we no longer need the representative_ field column now, since the purpose of each field will be implicit in its name.
For the 3-column view, it sounds like we're essentially morphing the "mfde" IDL (view) class from the working branch, teaching it to understand config. display_ field_map / multi, to JSON-ify the data, and to drop a few unneeded fields. And I assume the "name" column would be config. display_ field_map. name, which we'll require to be unique.