- Vue 74.1%
- JavaScript 24.4%
- Python 1.1%
- Shell 0.3%
This feature allows custom form dialog construction via config, as well as TTL template
specification, which is then string-serialized using the user inputs upon form save, followed
by adding the parsed quads to the graph store. This is a powerful feature that allows
arbitrarily complex user input and metadata linkage via relatively simple primitive form
input configuration. These wizard editors can be configured to appear for any class.
These are the working principles:
- a new wizard is declared and configured via the new 'wizard_editors' option, which allows
several standard options along with the important: an array of 'inputs' and the 'template'
- 'inputs' have to specify the 'type', among other rendering options; currently supported
'type's include 'text', 'text-paragraph', and 'boolean'. The plan is to extend these
substantially, possibly driven by LinkML types provided by a specific schema, but also
allowing already supported 'shacl-vue' editors. Each 'input' configures the associated
input component in the wizard form, and they will render in the order provided via
configuration.
- 'input's also have to specify a unique 'prop', which becomes the field name through which
this input is referenced, both in 'shacl-vue' internals and inside the TTL template.
- the 'template' should be a TTL string, with to-be-populated field names inside
'curly brackets'. Field names include all 'prop's configured for 'input's, as well as
'pid', which refers to the identifty of the current record being edited and from which
the wizard is launched. TTL can either be supplied directly as a string, or as a URL via
the existing 'content' option.
- declared wizards are configured for rendering for specific classes via the new option
'wizard_editor_selection'.
- wizards can be supplied with icons via configuration; these can come in different formats:
- an 'mdi-' string which will render any of the standard free 'mdi' icons
- an svg string, which will be rendered as is
- a 'content:' pointer to an SVG file, which will be loaded and rendered as is
Importantly, any SVG used in this context should have a viewport or width/height of 24x24 px
This commit includes a documentation update that covers all details related to the wizard
editor feature, extensively.
To achieve the above, the following major code changes were done:
- The 'NodeShapeEditor', which renders for a given record when it is being created or edited
inside the 'FormEditor', will check the 'wizard_editor_selection' to see if any wizards need
to be made available for the current record type (a.k.a. class). If yes, it will render those
as buttons at the top of the form below the 'All fields' button. The wizards render as clickable
buttons, with customizable tooltips and icons, which will open a dialog when clicked, passing
along all config options related to the selected wizard
- The new 'WizardEditor' will render inside the dialog. It will display all general config
options of the wizard, and will then render a row per input. Inputs have their own descriptions
and validation rules embedded (taken from config). Reset and Cancel buttons are self-explanatory.
The save button will run validation on all inputs, and on successful validation will emit a 'save'
event to the parent component ('NodeShapeEditor'), also passing along all entered input values.
- On detecting a 'save' event from a wizard, the 'NodeShapeEditor' will:
- receive the input values and declare them as 'wizardData'
- add the node ID of the current record to the 'wizardData' under the 'pid' field, which is how
the record can be referenced inside the TTL template
- pass 'wizardData' to the existing 'fillStringTemplate' utility function to render valid TTL
output
- pass the TTL to 'rdfDS.parseTTLandDedup(newTTL)' that outputs quads and adds them to the graph
store
- 'rdfDS.parseTTLandDedup(newTTL)' returns all the quads that were parsed and added to the graph
store. These are now process individually. Importantly, if an added quad has a subject value that
is identical
to the current node ID, we delete it from the graph store, because it uses a nonsense named node
(the node ID of the record, which is not reproducibly identical to the record PID). However, we
also add the quad's object to the 'formData' under the index of the current node and the quad's
predicate, in order to keep linkage to the TTL-parsed quads. Importantly, the existing standard
functionality that runs when saving a form (for record creation or editing) will then take care
of adding the correct quads to the graph store to replace those that were deleted.
- Continuing with the individual processing of quads that were parsed from TTL and added to the graph
store, if an added quad has a subject value that is NOT identical to the current node ID, AND it
is a named node, this means that a new record has been added to the graph store and it is therefore
eligible for submission. This is added to 'savedNodes' and 'nodesToSubmit', as well as a separate
'NodeShapeEditor'-specific tracker of all wizard-added quads.
- Garbage cleanup is also necessary in the case where quads were added to the graph store by a wizard
but the form was then subsequently cancelled. To deal with this, 'NodeShapeEditor' registers a form
cancel handler via the existing 'registerHandler' functionality, which will delete all the relevant
quads.
Lastly, for improved UI the headings of 'property groups' in the 'NodeShapeEditor' have been
removed. This is in anticipation of the complete removal of parent-class-based grouping of
properties inside the 'NodeShapeEditor'.
|
||
|---|---|---|
| .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