This implements half of #229 and half of #228. Showing record types or all properties in the detail view is not yet implemented, although some of the logic introduced in this branch could be reused for that purpose. I wanted to go all the way, but did not manage to go beyond the record list because of time constraints and distractions.
The autoColumnsDefinitions callback from frontend/vre/record/record.list.view.js was outfactored to frontend/vre/utils/tabulator-utils.js and then extended to always include all possible properties as available columns. The set of visible columns is still determined in the same way, though the decision to make a column visible now happens in a different place. For the extended logic, I used the MappedCollection feature from the freshly outfactored, still-to-be-released backbone-collection-transformers.
Then, I added an icon column to convey the record type: a person silhouette for a biographical record, a book for a bibliographical record. The HTML for the icon is rendered using a Mustache template. That template is potentially reusable for a Backbone.View. The HTML includes textual labels for screen readers. Record types are indicated at the individual record level rather than the catalog level, because I seemed to recall that some catalogs are mixed.
The new code lacks tests, but it has a low complexity and I hope it is sufficiently documented.
This branch has some side effects:
The docker-compose postgres service port is no longer forwarded to the host. This was never necessary to make docker-compose work. The reason to remove it is that it somehow prevented me from starting the container.
I turned the filter input for the Title column from a <textarea> back into a default <input>, because the height difference with other columns annoyed me.
I fixed a typo in the edpop-record-ontology.json that I discovered by coincidence.
As an aside, I notice that edpoprec:BiographicalRecord is a subclass of edpoprec:Record while edpoprec:BibliographicalRecord isn't. Conversely, BibliographicalRecord has a cardinality constraint while BiographicalRecord doesn't. I did not address this because I didn't know whether it was merely an oversight or whether there was a good reason for it.
This implements half of #229 and half of #228. Showing record types or all properties in the detail view is not yet implemented, although some of the logic introduced in this branch could be reused for that purpose. I wanted to go all the way, but did not manage to go beyond the record list because of time constraints and distractions.
The
autoColumnsDefinitionscallback fromfrontend/vre/record/record.list.view.jswas outfactored tofrontend/vre/utils/tabulator-utils.jsand then extended to always include all possible properties as available columns. The set of visible columns is still determined in the same way, though the decision to make a column visible now happens in a different place. For the extended logic, I used theMappedCollectionfeature from the freshly outfactored, still-to-be-released backbone-collection-transformers.Then, I added an icon column to convey the record type: a person silhouette for a biographical record, a book for a bibliographical record. The HTML for the icon is rendered using a Mustache template. That template is potentially reusable for a
Backbone.View. The HTML includes textual labels for screen readers. Record types are indicated at the individual record level rather than the catalog level, because I seemed to recall that some catalogs are mixed.The new code lacks tests, but it has a low complexity and I hope it is sufficiently documented.
This branch has some side effects:
postgresservice port is no longer forwarded to the host. This was never necessary to make docker-compose work. The reason to remove it is that it somehow prevented me from starting the container.<textarea>back into a default<input>, because the height difference with other columns annoyed me.edpop-record-ontology.jsonthat I discovered by coincidence.As an aside, I notice that
edpoprec:BiographicalRecordis a subclass ofedpoprec:Recordwhileedpoprec:BibliographicalRecordisn't. Conversely,BibliographicalRecordhas a cardinality constraint whileBiographicalRecorddoesn't. I did not address this because I didn't know whether it was merely an oversight or whether there was a good reason for it.