File upload support for wizard feature #329

Merged

jsheunis merged 1 commit from wizuploader into main

2026-02-10 21:58:26 +00:00

jsheunis commented

2026-02-10 21:49:59 +00:00

Owner

addresses two thirds of datalink/shacl-vue#323

This required or went along with several features:

Updated gitannex_p2phttp_config config structure to allow specifying multiple targets and multiple repositories
A new component GitAnnexUploader4Wiz that emits its uploaded data via update:modelValue on successful upload, allowing parent components to instantiate it with v-model
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.

addresses two thirds of https://hub.psychoinformatics.de/datalink/shacl-vue/issues/323 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: ```yaml 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`: ```yaml 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.

jsheunis added 1 commit

2026-02-10 21:49:59 +00:00

File upload support for wizard feature dd9e951952

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.