Plugin modules/components, new wizard input types, Nunjucks templating, more #346

Merged

jsheunis merged 4 commits from wizard-more into main

2026-03-18 21:17:24 +00:00

jsheunis commented

2026-03-18 21:04:47 +00:00

Owner

Support autoregistration of plugin modules and components

This provides shacl-vue with the ability to support the use of plugin modules and plugin
components. The existing index.js now also lets the app use runtime-plugins, which is
a catch-all for all plugin code that is included in 'runtime-plugins/plugin_name/' before
the the application is built with Vite. The plugin module should be located at
'runtime-plugins/plugin_name/index.js' and any components should be located at
'runtime-plugins/plugin_name/*.vue' in order for them to be autoregistered. These plugins
are then made available to any component in the whole via inject('runtimePlugins'). Plugin
module exports are then available at runtimePlugins['plugin_name'].api and plugin components
are available at runtimePlugins['plugin_name'].components.

This functionality allows complex and domain-specific logic and UI to be inclued in a
shacl-vue build, while shacl-vue keeps its domain-agnosticity. It was developed in part
because of the need to inject complex functionality and rendering logic into the wizard
editor mechanism.

Support nunjucks templating for wizardeditor feature

Before this, the fillStringTemplate method was a simple, and the only, template filling
procedure that replaced variables in a string template, surrounded by curly braces, with
their values. No logic, no loops, no further support. This was not sufficient for cases
where the wizardeditor needed to support inputs of type arrays or objects. With previous
experience with jinja, nunjucks looked like a sensible library to add such support.

Templates included via the existing 'content' configuration option can now also be supplied
as nunjucks templates. These have to have the string '.nunjucks' precede the extension of
the filename, in order to be recognized as a nunjucks template. E.g. 'MyTemplate.nunjucks.ttl'.
New utility and configuration composable code allows getting the template type, and the
wizardeditor will use this type to either call the existing fillStringTemplate function,
or the new nunjucks code supplied by the new useNunjucks composable.

Extended input type and component support for WizardEditor

Before this the WizardEditor only supported a single level of inputs of basic types,
meaning no arrays, no objects, and no recursion. The DOI metadata import use case
quickly showed that the previous state was not sufficient at all.

This commit introduces support for arrays, objects, indefinite recursion, and buttons.
Arrays are configured by input key-value 'multi_valued: true'. Objects are configured
by input type 'object' and can receive its child-level input specification via its own
'inputs' key. Buttons are configured by input type 'button' and can specify which
function to run via the 'on_click.call' option. If in addition the 'on_click.plugin'
is provided, the function to call will be retrieved from the context of the provided
(and presumably autoregistered) plugin.

Additional support is also provided for rendering a custom component inside the
WizardEditor component, as opposed to the current approach of rendering each input
based on config specification. The component feature was also introduced when it became
clear that the complexity of the DOI metadata import use case could not be achieved using
the standard input specification use case. Custom components are specified via the root
'component' key for a given wizard spec, and its value should be provided in the format
'plugin_name:component_name'.

Here is an example wizard configuration using all new options:

DOIImportWizard:
  name: DOI Import Wizard
  component: doi:DOIFetcher
  inputs:
    - prop: doi
      type: text
      required: true
    - prop: import
      type: button
      on_click:
        plugin: doi
        call: importMetadata
    - prop: title
      type: text
      required: true
    - prop: abstract
      type: text-paragraph
    - prop: authors
      type: object
      multi_valued: true
      inputs:
        - prop: pid
          type: text
        - prop: given_name
          type: text
        - prop: family_name
          type: text
        - prop: role
          type: text
          multi_valued: true
  template: content:DOIImportWizardTemplate

To support the new input specifications, the WizardEditor was refactored into a set of
self-contained components that support recursion.

Finally, the WizardEditor also supports the rendering of a custom component instead of
configured inputs. When a component is specified, it will be rendered instead of all
specified inputs. It is important to note that these inputs that will be used for the
template-filling procedure of the wizard should all still be specified, as they are used
by the WizardEditor to manage state between parent/child components and between the wizard
and the templating mechanism.

## Support autoregistration of plugin modules and components This provides shacl-vue with the ability to support the use of plugin modules and plugin components. The existing index.js now also lets the app use runtime-plugins, which is a catch-all for all plugin code that is included in 'runtime-plugins/plugin_name/' before the the application is built with Vite. The plugin module should be located at 'runtime-plugins/plugin_name/index.js' and any components should be located at 'runtime-plugins/plugin_name/*.vue' in order for them to be autoregistered. These plugins are then made available to any component in the whole via inject('runtimePlugins'). Plugin module exports are then available at runtimePlugins['plugin_name'].api and plugin components are available at runtimePlugins['plugin_name'].components. This functionality allows complex and domain-specific logic and UI to be inclued in a shacl-vue build, while shacl-vue keeps its domain-agnosticity. It was developed in part because of the need to inject complex functionality and rendering logic into the wizard editor mechanism. ## Support nunjucks templating for wizardeditor feature Before this, the fillStringTemplate method was a simple, and the only, template filling procedure that replaced variables in a string template, surrounded by curly braces, with their values. No logic, no loops, no further support. This was not sufficient for cases where the wizardeditor needed to support inputs of type arrays or objects. With previous experience with jinja, nunjucks looked like a sensible library to add such support. Templates included via the existing 'content' configuration option can now also be supplied as nunjucks templates. These have to have the string '.nunjucks' precede the extension of the filename, in order to be recognized as a nunjucks template. E.g. 'MyTemplate.nunjucks.ttl'. New utility and configuration composable code allows getting the template type, and the wizardeditor will use this type to either call the existing fillStringTemplate function, or the new nunjucks code supplied by the new useNunjucks composable. ## Extended input type and component support for WizardEditor Before this the WizardEditor only supported a single level of inputs of basic types, meaning no arrays, no objects, and no recursion. The DOI metadata import use case quickly showed that the previous state was not sufficient at all. This commit introduces support for arrays, objects, indefinite recursion, and buttons. Arrays are configured by input key-value 'multi_valued: true'. Objects are configured by input type 'object' and can receive its child-level input specification via its own 'inputs' key. Buttons are configured by input type 'button' and can specify which function to run via the 'on_click.call' option. If in addition the 'on_click.plugin' is provided, the function to call will be retrieved from the context of the provided (and presumably autoregistered) plugin. Additional support is also provided for rendering a custom component inside the WizardEditor component, as opposed to the current approach of rendering each input based on config specification. The component feature was also introduced when it became clear that the complexity of the DOI metadata import use case could not be achieved using the standard input specification use case. Custom components are specified via the root 'component' key for a given wizard spec, and its value should be provided in the format 'plugin_name:component_name'. Here is an example wizard configuration using all new options: ```yaml DOIImportWizard: name: DOI Import Wizard component: doi:DOIFetcher inputs: - prop: doi type: text required: true - prop: import type: button on_click: plugin: doi call: importMetadata - prop: title type: text required: true - prop: abstract type: text-paragraph - prop: authors type: object multi_valued: true inputs: - prop: pid type: text - prop: given_name type: text - prop: family_name type: text - prop: role type: text multi_valued: true template: content:DOIImportWizardTemplate ``` To support the new input specifications, the WizardEditor was refactored into a set of self-contained components that support recursion. Finally, the WizardEditor also supports the rendering of a custom component instead of configured inputs. When a component is specified, it will be rendered instead of all specified inputs. It is important to note that these inputs that will be used for the template-filling procedure of the wizard should all still be specified, as they are used by the WizardEditor to manage state between parent/child components and between the wizard and the templating mechanism.

jsheunis added 4 commits

2026-03-18 21:04:48 +00:00

update dlthings namespace url to v2 8c96c8d5d8

Support autoregistration of plugin modules and components 3727891913

This provides shacl-vue with the ability to support the use of plugin modules and plugin
components. The existing index.js now also lets the app use runtime-plugins, which is
a catch-all for all plugin code that is included in 'runtime-plugins/plugin_name/' before
the the application is built with Vite. The plugin module should be located at
'runtime-plugins/plugin_name/index.js' and any components should be located at
'runtime-plugins/plugin_name/*.vue' in order for them to be autoregistered. These plugins
are then made available to any component in the whole via inject('runtimePlugins'). Plugin
module exports are then available at runtimePlugins['plugin_name'].api and plugin components
are available at runtimePlugins['plugin_name'].components.

This functionality allows complex and domain-specific logic and UI to be inclued in a
shacl-vue build, while shacl-vue keeps its domain-agnosticity. It was developed in part
because of the need to inject complex functionality and rendering logic into the wizard
editor mechanism.

Support nunjucks templating for wizardeditor feature fe85c08ccc

Before this, the fillStringTemplate method was a simple, and the only, template filling
procedure that replaced variables in a string template, surrounded by curly braces, with
their values. No logic, no loops, no further support. This was not sufficient for cases
where the wizardeditor needed to support inputs of type arrays or objects. With previous
experience with jinja, nunjucks looked like a sensible library to add such support.

Templates included via the existing 'content' configuration option can now also be supplied
as nunjucks templates. These have to have the string '.nunjucks' precede the extension of
the filename, in order to be recognized as a nunjucks template. E.g. 'MyTemplate.nunjucks.ttl'.
New utility and configuration composable code allows getting the template type, and the
wizardeditor will use this type to either call the existing fillStringTemplate function,
or the new nunjucks code supplied by the new useNunjucks composable.

Extended input type and component support for WizardEditor d050912ea5

Before this the WizardEditor only supported a single level of inputs of basic types,
meaning no arrays, no objects, and no recursion. The DOI metadata import use case
quickly showed that the previous state was not sufficient at all.

This commit introduces support for arrays, objects, indefinite recursion, and buttons.
Arrays are configured by input key-value 'multi_valued: true'. Objects are configured
by input type 'object' and can receive its child-level input specification via its own
'inputs' key. Buttons are configured by input type 'button' and can specify which
function to run via the 'on_click.call' option. If in addition the 'on_click.plugin'
is provided, the function to call will be retrieved from the context of the provided
(and presumably autoregistered) plugin.

Additional support is also provided for rendering a custom component inside the
WizardEditor component, as opposed to the current approach of rendering each input
based on config specification. The component feature was also introduced when it became
clear that the complexity of the DOI metadata import use case could not be achieved using
the standard input specification use case. Custom components are specified via the root
'component' key for a given wizard spec, and its value should be provided in the format
'plugin_name:component_name'.

Here is an example wizard configuration using all new options:

DOIImportWizard:
  name: DOI Import Wizard
  component: doi:DOIFetcher
  inputs:
    - prop: doi
      type: text
      required: true
    - prop: import
      type: button
      on_click:
        plugin: doi
        call: importMetadata
    - prop: title
      type: text
      required: true
    - prop: abstract
      type: text-paragraph
    - prop: authors
      type: object
      multi_valued: true
      inputs:
        - prop: pid
          type: text
        - prop: given_name
          type: text
        - prop: family_name
          type: text
        - prop: role
          type: text
          multi_valued: true
  template: content:DOIImportWizardTemplate

  To support the new input specifications, the WizardEditor was refactored into a set of
  self-contained components that support recursion.

  Finally, the WizardEditor also supports the rendering of a custom component instead of
  configured inputs. When a component is specified, it will be rendered instead of all
  specified inputs. It is important to note that these inputs that will be used for the
  template-filling procedure of the wizard should all still be specified, as they are used
  by the WizardEditor to manage state between parent/child components and between the wizard
  and the templating mechanism.

jsheunis merged commit 3c5ad7456e into main

2026-03-18 21:17:24 +00:00

jsheunis referenced this pull request from a commit

2026-03-18 21:17:26 +00:00

Merge pull request 'Plugin modules/components, new wizard input types, Nunjucks templating, more' (#346) from wizard-more into main