Refactor/rewrite MappingBrowser

[stefandesu]

MappingBrowser should be remade from scratch, possibly using multiple components that integrate with each other. The current functionality of MappingsApp should also be integrated in MappingBrowser.

[nichtich]

The component could also be merged again with MappingApp (related: #189) and provide a container for at least three modes/tabs/subcomponents/...:

• Concordances: list of concordances (as implemented in MappingApp)
• Mappings: list of existing mappings (as implemented in MappingApp but also other sources such as locally stored mappings)
• Matches: existing mappings and mapping recommendations between selected concepts (current MappingBrowser)

This would require to rename current MappingBrowser to MatchesBrowser and add two components ConcordanceBrowser and new MappingsBrowser.

[stefandesu]

I'm wondering how much logic MappingBrowser should have by itself. Should it be able to load the data (e.g. using Cocoda's providers) by itself (1), should it use Cocoda's provided methods (via the objects mixin) (2), or should it be "dumb" and only display data (3)?

(1) would have the advantage that the component could be used separately somewhere outside of Cocoda and still have the full functionality, but we'd need to provide ways to integrate it deeper into Cocoda (by using event emitters etc.).

(2) would be the easiest, but it would be coupled with Cocoda and we wouldn't be able to use the component somewhere else.

(3) would separate the loading logic from the displaying, but we would need even more event emitters and stuff (for example an event for "user selected this concordance, please load the data"), and every place where the component is used would need to have its own logic of providers/registries and how to load the data.

I'm a little conflicted with this. What do you say, @nichtich?

[stefandesu]

Here's the result of today's planning meeting about MappingBrowser:

• selection of registries (similar to current selection) at the top
• 3 tabs: Concordances, Mapping Search, Mapping Navigator
• Concordances:
  • list all concordances
  • filter by schemes
  • button to show mappings for a concordance (opens "Mapping Search")
• Mapping Search:
  • list mappings for those registries that support listing/filtering/sorting all mappings
  • one section per available registry
  • filters: vocabularies, concepts, concordance, creator, type, ...
  • sorting (e.g. by vocabularies, concept notations, creator, date, ...)
  • pagination within each section
• Mapping Navigator (name to be discussed), basically today's Mapping Browser:
  • shows mappings for currently selected concepts
  • one section per available registry
  • sorting
  • pagination within each section
  • options:
  • show results of all concepts schemes (default on)
  • always show all mappings and suggestions (we might need to remove this option in favor of pagination, default off)
  • new: hide empty sections (default ?)
• As this is a core part of Cocoda, we'd use option (2) of my previous comment for implementation. In the future, we could make Cocoda more flexible by adding a build option to only show the Mapping Browser, not the other parts of the application.

Future features:

• list editing mode (#239)

[stefandesu]

Note: I would move the part about sorting to a later version (possibly 0.9.1) because it requires further logic in both jskos-server and probably vue-flexible-table.

[stefandesu]

The rewrite is now finally merged in dev!

Some features are still missing, but they will be handled in further issues:

• MappingSearch: limit search by date #360
• MappingBrowser: Add share link for Mapping Search #361
• MappingBrowser: Add API URL to data modal #363
• MappingBrowser: Add sorting to mapping tables #365
• MappingBrowser: More settings #366
• MappingBrowser - Navigator: Add proper pagination #367