1. add Vue devtools support
2. update project dependencies
3. refactor configurator source code tree for private library hook
4. fix build issue
5. dynamic load scenario JSON schema(fix cache issue)
6. add vjsf 1.12.2 (latest) for private package dependencies
7. remove vjsf unnecessary files
8. use private vjsf as configurator dependencies
9. Add custom IVSHMEM_REGION widget
10. add a script to populate default values
11. get default values before export scenario xml
12. specify widgets in XML schema
13. add missing vjsf license file
14. populate default values to empty nodes
15. when user clicks save button, update formData with each field default value
16. fix when the user clicks the save button will collapse configFom
17. add success message for saving scenario XML
vue-json-schema-form 1.12.2 (latest)link: b30ea7c2d6/packages/lib
Tracked-On: #6691
Signed-off-by: Weiyi Feng <weiyix.feng@intel.com>
Different from other nodes which have static default values, the virtual
BDF nodes of virtual UART endpoints or IVSHMEM interfaces have a set of
default values and should be used with uniqueness guaranteed. The existing
default value mechanism in XSD does not include support for this.
This patch adds two more ACRN-specific annotations, namely `acrn:defaults`
and `acrn:unique-among`, that have the following semantics.
- `acrn:defaults` is a Python expression that evaluates to an iterable.
- `acrn:unique-among` is an xpath that specifies the nodes. Each node
within the select ones shall have a value unique among them. The xpath
is evaluated with the variable `parent` defined as the parent node
under which the vBDF node is to be appended.
Tracked-On: #7330
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
We plan to add the following attributes to element definitions in the XML
schema:
- acrn:applicable-vms, which specify if an element applies to a
pre-launched VM, the service VM or a post-launched VM
- acrn:views, which specify if an element shall appear in the basic or
advanced tab in the configurator.
In order to reduce the attributes above to existing XML technologies, we
need to create new complex types that lists all config items that applies
to a pre-launched VM, the service VM or a post-launched VM, or that should
be shown in the basic or advanced view. Such types can then be used to
replace the original, all-in-one type during validation or configurator
rendering.
When unspecified, an element always applies under all possible
circumstances.
To realize this slicing mechanism, this patch adds a generic class
implementing the common part of slicing XML schema types and two
specific-purpose slicers according to the applicable VMs or views
attributes.
v2 -> v3:
* Update configdoc.xsl to recognize types in xs:alternative nodes.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Today the scripts that populate default values and validate scenarios have
different command-line interfaces: the former requires an XML schema as
input (which is cumbersome in most cases), while the latter always infer
where the XML schema is (which is inflexible).
This patch unifies the command line options of those scripts as follows:
- The scenario XML is always a required positional argument.
- The output file path (if any) is an optional positional argument.
- The schema XML file is an optional long option. When not specified, the
scripts will always use the one under the misc/config_tools/schema
directory.
Also, this patch makes the validator.py executable, as is done to other
executable scripts in the repo.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
There is an increasing demand of composing different operations around XML
schemas and/or data in different ways for different purpose. Today we
already have:
- Validate XML data, which takes XML schemas and data (board and
scenario) as inputs.
- Fill in missing nodes in XML data with default values, which takes XML
schema and data (scenario only) as inputs.
In the near future we'll extend the operations around XMLs by introducing
XML schema preprocessing and XML data upgrading, adding more possibilities
to construct a larger operation by composing smaller ones.
In order for minimized code repetition and easier composition, this patch
introduces an infrasturcture that abstracts each operation as a pipeline
stage. Each stage defines its own inputs and outputs and can be composed
sequentially as a larger, single operation.
The existing operations listed above, along with XML file loaders, are then
refactored to provide pipeline stages. The main methods are also refined to
complete their tasks by constructing and invoking pipelines.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Today the default value populator will always create a node if it is
required by the schema but not provided in the given XML file. This could
hide issues in a given scenario XML if a node does not have default
values (i.e. require user's inputs) but accepts empty text.
This patch avoids the creation of nodes without a default value so that, at
validation stage, missing of essential data is always reported.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Today the script default_populator.py fills in default values by visiting
an XML schema and an XML tree simultaneously and add a node to the latter
whenever one satisfying the schema does not exist. This visiting logic is
not only useful for filling in default values, but also for upgrading
XMLs to new schemas.
This patch abstracts the flow of the visiting above as a separate class,
just like tree visitors or transformers. The current default value
populator is then refactored to extend that class by inheritance.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The default value population algorithm introduced by commit
2bfaa34 ("config_tools: populate default values in scenario XML") only
populates default values to the first occurrence of a tag when the tag is
specified to allow multiple occurrences under an xs:all node. This may lead
to incomplete scenario XML as some of the default values are missed.
This patch fixes this issue by checking **all** nodes having the same tag
under a node specified by an xs:all schema.
Fixes: 2bfaa34 ("config_tools: populate default values in scenario XML")
Tracked-On: #6292
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
While we have default values of configuration entries stated in the schema
of scenario XMLs, today we still require user-given scenario XMLs to
contain literally ALL XML nodes. Missing of a single node will cause schema
validation errors even though we can use its default value defined in the
schema.
This patch allows user-given scenario XMLs to ignore nodes with default
values. It is done by adding the missing nodes, all containing the defined
default values, to the input scenario XML when copying it to the build
directory. This approach imposes no changes to either the schema or
subsequent scripts in the build system.
Tracked-On: #6292
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Weiyi-Feng