File upload support for wizard feature #329
Merged
jsheunis
merged 1 commit from 2026-02-10 21:58:26 +00:00
wizuploader into main
1 commit
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| dd9e951952 |
File upload support for wizard feature
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.
|
