- Vue 74.1%
- JavaScript 24.4%
- Python 1.1%
- Shell 0.3%
This required or went along with several features:
1. Updated 'gitannex_p2phttp_config' config structure to allow specifying multiple
targets and multiple repositories
2. A new component 'GitAnnexUploader4Wiz' that emits its uploaded data via 'update:modelValue'
on successful upload, allowing parent components to instantiate it with v-model
3. An updated 'wizard_editor_selection' config sub-option that allows wizards to be rendered for
any class containing a specified slot
Updated 'gitannex_p2phttp_config' config structure:
It is actually a new config option specifically used for the wizard uploader component, so that
we can remain backwards compatible (at least for a while) with the existing config option used for
the 'InstancesUploadEditor'. The option allows specification of multiple upload targets, and multiple
repositories per target. For example:
gitannex_p2phttp_config_wizard:
client_uuid: pool-ui
targets:
- name: My Code Hub
base_url: https://my-code-hub.org
repositories:
- name: File Upload Repo 1
annex_uuid: <uuid1>
- name: File Upload Repo 2
annex_uuid: <uuid2>
- name: Some other Hub
base_url: https://some-other-hub.org
repositories:
- name: Some other Repo
annex_uuid: <uuid3>
'GitAnnexUploader4Wiz' component:
The new component is introduced specifically to be used by the 'WizardEditor' and with the new
'gitannex_p2phttp_config_wizard' config. If there are multiple upload targets configured, a selector
will be shown. For the selected target, if there are multiple repositories configured, another selector
will shown. If there are only one of each, no selectors will be shown. The user uploads a file and on
successful upload, the file data will show. The wizard is then saved, and data are emitted upwards to be
handled by the 'WizardEditor' parent component.
Emitted data is an object with keys: 'name','size','type','ext','hash','url','annexKey','downloadUrl'.
Along with this component, a new input 'type' is supported for 'wizard_editors' configuration: 'upload'.
Updated 'wizard_editor_selection' config:
This now has a new sub-option '_slots' that allows wizards to be rendered for any class containing a
specified slot. For example, the following specifies that the 'FileUploadWizard' will be shown in the
'_record' context for any class that has a slot 'dlthings:distributions':
wizard_editor_selection:
_slots:
dlthings:distributions:
_record:
- FileUploadWizard
Additional changes:
The fact that the 'GitAnnexUploader4Wiz' emits its data to the 'WizardEditor', which then needs to use
it (together with other input data of the same wizard) to fill the provided TTL template, posed a challenge.
This is because the upload component emits an object, whereas previously the TTL template string serialization
only dealt with primitive values. This required the 'fillStringTemplate' utility function to be updated to
support resolving dot notation. This means properties of the data emitted by the upload component can be
referenced in the TTL template using dot notation, and with the configured input 'prop' as the main object,
for example: if for 'wizard_editors' a wizard ios configured with prop 'file' (and with type 'upload'), then
uploaded file properties can be referenced as e.g. '{file.size}'.
Then, the 'useWizard' composable needed to be updated to allow both the 'showWizardGroup' and 'setupWizards'
functions to deal with the new 'wizard_editor_selection' sub-option '_slots', to identify which wizards to
render, if any, for any given context. In addition, a new function was added here: 'onFormWithWizardSave'.
This was needed to deal with an edge case that was missing before, and which came to light specifically in
the file uploader use case. The template includes an RDF statement where the parent record ID is the object.
In the existing version of 'handleWizardSave', such a quad is just added to the graph with no special treatment.
However, this record ID might not be the true PID of the parent record, which is only definitively known on
form save. This is why a new 'onFormWithWizardSave' function was introduced, specifically to be used for
wizards in the '_record' context. When a form with a wizard is saved, this handler (which needs to be
explicitly registered) will run through all quads that were saved to the graph by a wizard and it will search
for quads where the record ID is the object. It will then compare the record id to the correct PID. If theye
are the same, nothing is to be done. If they differ, the incorrect quad is removed from the graph and a new
quad, with same subject+predicate but with the correct PID as object, is added to the graph.
|
||
|---|---|---|
| .forgejo/workflows | ||
| .github/workflows | ||
| docs | ||
| public | ||
| src | ||
| tests | ||
| tools | ||
| .browserslistrc | ||
| .codespellrc | ||
| .editorconfig | ||
| .gitignore | ||
| .npmignore | ||
| .prettierignore | ||
| .prettierrc | ||
| index.html | ||
| index.js | ||
| jsconfig.json | ||
| LICENSE | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| vite.config.app.mjs | ||
| vite.config.lib.mjs | ||
shacl-vue
THIS REPOSITORY IS UNDER CONTINUOUS DEVELOPMENT
Overview
shacl-vue is a web-based user interface for entering, editing, and viewing linked (meta)data using a VueJS application driven by the Shapes Constraint Language (SHACL).
Think of it as an automatic builder that you just have to feed with a model of your data. If you have a SHACL schema, or a schema in a format that can be exported to SHACL, then you're good to go. No need to build custom forms for data entry, no need to struggle with post-entry data validation, no need to create a catalog application that renders all the entered data. shacl-vue does all of this automatically.
shacl-vue is built with VueJS 3, Vuetify frontend components, and Vite build tools, and was heavily inspired by the WC3 Draft: Form Generation using SHACL and DASH. For reading, manipulating, and writing RDF data (including SHACL), the package uses libraries compatible with the RDF/JS specifications (see also: https://github.com/rdfjs-base)
Links
- For an example of a deployed
shacl-vueinstance, see the metadata annotation tool of the TRR379 Research Consortium - Refer to the documentation for more information.
Installation and usage
shacl-vue can be installed from npm:
npm install shacl-vue
Use as a library
The npm package currently provides the named export ShaclVue:
import { ShaclVue } from 'shacl-vue'
This is the main configurable VueJS component that is used to render all functionality of shacl-vue. It can be instantiated inside a VueJS application as follows:
<template>
<ShaclVue :configUrl="myconfig"></ShaclVue>
</template>
<script setup>
const myconfig = 'config.json';
</script>
Here, config.json is used to configure the properties of the specific shacl-vue deployment. See examples here, and here.
For the above to work, the VueJS application will have to install Vuetify and the ShaclVue might need to be registered explicitly.
Use as a standalone site
The build steps of shacl-vue produce both the library as well as a set of static files that can be served as a standalone site. The abovementioned metadata annotation tool of the TRR379 Research Consortium deploys shacl-vue in this manner, and its source code can be viewed here.
To use shacl-vue to deploy a standalone site, follow the build steps below. In addition, a deployment-specific confi file should be provided.
Local development and building
The shacl-vue source code can be cloned for local development, testing, or building. First clone the repository:
git clone https://hub.psychoinformatics.de/datalink/shacl-vue.git
cd shacl-vue
Then create a local NodeJS virtual environment, e.g with micromamba:
micromamba create -n <my-env-name> nodejs
micromamba activate <my-env-name>
Then install the application:
npm install .
Local rendering during development
To serve the application locally in order to test it in the browser, run:
npm run dev
Build steps
To build the library (output at /dist/lib):
npm run build:lib
To build the standalone site, i.e. VueJS application (output at /dist/app):
npm run build:app
To build both the library and the standalone site:
npm run build
Testing
Testing remains a primary TODO for this package, although a minimal test is in place to check whether the named exports can be imported into a new project. Testing is done with Vitest.
npm run test
Dependency on shacl-tulip
In an effort to generalize shacl-vue for improved use by and interoperability with other applications, the underlying functionality was factored out and packaged as the shacl-tulip library (like "shacl-vue-lib"). shacl-tulip provides the main (derived) classes for handling RDF data and related form data. It is completely independent of VueJS, yet class constructors allow passing reactive objects as arguments, which shacl-tulip handles seamlessly. It also focuses purely on library-level functionality (including utilities that were previously part of shacl-vue), and contains no frontend code. shacl-vue imports shacl-tulip classes and uses them mainly in its composable code.
Access to external webservices
Unless configured to connect to specific API endpoints (see Service API integration docs), a client accessing a bundled shacl-vue deployment does not load any external resources. All required resources are loaded from the server where the bundled application is hosted.
Acknowledgements
This work was funded, in part, by
- Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under grant TRR 379 (546006540, Q02 project)
- Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under grant SFB 1451 (431549029, INF project)
- MKW-NRW: Ministerium für Kultur und Wissenschaft des Landes Nordrhein-Westfalen under the Kooperationsplattformen 2022 program, grant number: KP22-106A