Implement component factory for data viewing and entering

[jsheunis]

VueJS rendering is built on the concept of components. For any unit that needs rendering, a separate component can be created/authored. These components can be invoked programmatically as needed.

Practically, this means that if we have a schema that specifies e.g. an author of a dataset can be of type schema:Person or schema:Organization, we could create VueJS rendering components for both of these types, and any other arbitrary types. Application logic could then determine which component to use to render a given author depending on the data.

In addition, an automated matching procedure could be used to select the most appropriate rendering component from a factory of components, and to default to a generic component if no appropriate ones are found. This means that the factory could be added to in an ad hoc way without having to register a component explicitly in some deterministic way.

A first step towards developing such a component factory could be to work from an example schema that already has a minimal set of annotations that would assist the matching procedure. E.g. whether a component is supposed to render data or allow the user to enter data; or what type of data format needs to be rendered/entered (text / date / integer, etc). This is closely connected to, and likely dependent on, https://github.com/psychoinformatics-de/shacl-vue/issues/2.

[jsheunis]

The first, and insufficient, implementation of this is currently in: component factory and rule-set and mapping. This is insufficient because the rule-set is hardcoded into the PropertyShapeEditor component code, and the mapping is hardcoded into the globals module.

How could this be improved?

Firstly, we note the following explanation provided by the vite project setup, in relation to the .vue files located in the src/components directory:

Importing is handled by unplugin-vue-components. This plugin automatically imports .vue files created in the src/components directory, and registers them as global components. This means that you can use any component in your application without having to manually import it.

Thoughts:

• we shouldn't hardcode the ruleset for matching a component
• we shouldn't hardcode the list of possible components to match
• ideally, adding a new component should be as eas
• Can matching logic to be contained within component itself? If it were python I would create a base Component class and it would have an abstract method match which any inheriting class needs to overwrite, and it should contain the logic that would match the specific inheriting component.
• At runtime, the application needs to know which components it should iterate through. There should be some mechanism to make this list available, either in real-time or beforehand during the build step.

[jsheunis]

https://github.com/psychoinformatics-de/shacl-vue/pull/26 implements the basic design for such a component factory. This is specific to editors (not viewers), but the design for viewers will be a duplicate.

The main remaining feature will be to return a score from the matchers instead of a boolean match or no match. But this can be implemented as a new feature and does not have to form part of the open PR, nor would it be necessary to complete as a prerequisite to closing this issue.