Method and system for uniform expression of single-line command multi-step parameters based on scope markers and GUI isomorphic linkage

Abstract

The present application belongs to the field of data processing flow or workflow management, and specifically relates to a method and system for uniform expression of single-line command multi-step parameters and GUI isomorphic linkage based on scope marking, which comprises the steps of flow definition, command analysis, flow execution and interface generation. In the flow definition step, a corresponding step scope is declared for at least one executable step in the flow; and a default configuration is associated with each step scope; so that a single command can be used to structurally express all parameters of a multi-step flow, and zero-intermediate reversible mapping can be realized between the single command and a GUI form. The present application can reduce learning and maintenance costs while improving reproducibility and portability.

Description

Technical Field

[0001] This invention belongs to the field of data processing flow or pipeline management, specifically a method and system for unified expression of multi-step parameters of single-line commands based on scope marking and isomorphic linkage with GUI. Background Technology

[0002] In the field of data processing workflow or pipeline management, command-line interfaces (CLI) and graphical user interfaces (GUIs) are commonly used to configure and execute multi-step processes. However, in traditional implementations, the two are often separate: CLI users configure each step through scripts or command-line parameters; GUI users define the interface and parameter mapping for each tool step using dedicated configuration files such as XML / YAML, which are then translated into low-level commands by the engine. This separate architecture leads to problems such as cognitive fragmentation, increased maintenance points, and difficulty in behavior traceability. Existing solutions typically place the process structure in external files and do not natively support multi-step hierarchical expression within the commands, thus making it difficult to achieve single-source factual and strictly reversible conversion between GUI and CLI.

[0003] Current common solutions mainly fall into the following two categories:

[0004] One type is the GUI framework represented by Galaxy: This type of framework defines interface fields and parameter mappings through tools such as XML description files. At runtime, the scheduler translates form data into command-line calls; CLI users maintain parameter sets in separate scripts or configuration files. Synchronization between the two is maintained through a translation layer. This approach has the following drawbacks: it requires maintaining two sets of sources simultaneously—GUI configuration and CLI scripts—leading to high modification costs; writing and maintaining XML description files increases the development burden, causing the GUI and CLI to effectively become two separate sets of logic; the translation layer, acting as an intermediate representation, increases the risk of errors and version drift; and the actual source of parameters is scattered in multiple places, making auditing and traceability difficult.

[0005] Another type is the CLI framework represented by Nextflow: Workflow engines like Nextflow and Snakemake primarily manage parameters through domain-specific language scripts and configuration files. Users can pass parameters one by one in the command line or describe parameters centrally using separate configuration files (such as nextflow.config or YAML parameter files). For example, Nextflow supports using `-params-file` to load YAML or JSON files to pass multiple parameters, avoiding excessively long command lines. While this approach simplifies CLI usage, it still has the following drawbacks: it introduces additional configuration files, increasing the learning curve; single-line commands struggle to reproduce the complete structure and steps of a configuration-based pipeline / GUI form; it doesn't natively support GUI operations, requiring third-party adaptation software to provide GUI services; and it necessitates manually maintaining consistency among the DSL, GUI, and shell command line.

[0006] In summary, existing technologies either emphasize the GUI but require additional configuration to achieve CLI integration, or emphasize the CLI but require users to manage multi-step parameters themselves or rely on external configuration files. The lack of a direct and unified way to express fine-grained parameter settings at the GUI and CLI levels leads to the following problems:

[0007] 1) Users need to master two methods: GUI operation and CLI parameter configuration, which has a high learning cost;

[0008] 2) The implementation of GUI and CLI has overlapping logic. Modifying a process often requires updating both the GUI configuration and CLI script, resulting in high development and maintenance costs. Summary of the Invention

[0009] The purpose of this invention is to provide a method and system for unified expression of multi-step parameters of a single-line command based on scope marking and isomorphic linkage with a GUI. By introducing a command-line parameter mechanism, a single command can structurally express all parameters of a multi-step process and achieve zero-intermediary reversible mapping with the GUI form, reducing learning and maintenance costs and improving reproducibility and portability.

[0010] To achieve the above objectives, the present invention adopts the following technical solution:

[0011] A method for unified expression of multi-step parameters in a single-line command based on scope marking and isomorphic linkage with a GUI is used for parameter management of configurable multi-step processes, including the following steps:

[0012] S1. Process Definition: In the process control file:

[0013] Declare a corresponding step scope for at least one executable step in the process; and associate a default configuration with each step scope; the default configuration includes at least one of the following types:

[0014] a) Empty configuration, used to indicate that the step uses its own internal default parameters;

[0015] b) Inherited configuration, used to indicate that this step inherits the configuration from another specified step scope;

[0016] c) Control configuration, used to indicate the execution status of this step;

[0017] S2. Command parsing: Receives command line input containing parameters and scope identifiers. Based on the scope identifier, identifies the step scope that is explicitly enabled in the command line and binds the parameters located after the scope identifier until the next scope identifier or the scope terminator to the corresponding step scope. For step scopes that are not explicitly enabled in the command line, the default configuration associated with them in step S1 is applied.

[0018] S3. Process Execution: Based on the structured configuration mapping parsed from S2, execute each step of the process sequentially, where each step runs using parameters bound to its step scope;

[0019] S4. Interface Generation: Based on the step scope defined in step S1, generate the parameter configuration form for the corresponding step in the graphical user interface (GUI); wherein, the input fields of the GUI form correspond one-to-one with the scope identifier and its parameters in the command line.

[0020] Furthermore, in step S1, the scope of the step and its default configuration are declared through text syntax containing specific delimiters.

[0021] Furthermore, the format of the text syntax is::@step_name=default_value::.

[0022] Furthermore, the inheritance configuration is indicated by explicitly writing the name of the inherited step scope.

[0023] Furthermore, the control is configured as a numerical flag to indicate whether to skip the execution of this step.

[0024] Furthermore, the scope identifier is in the format @step_name:, and the scope terminator is in the format @:.

[0025] Furthermore, in step S2, the first occurrence priority rule is used to process parameters with the same name at different levels.

[0026] Furthermore, in the S4 interface generation step, the user input values ​​received by the GUI form can be converted into equivalent command-line parameters containing scope identifiers.

[0027] A parameter management system for configurable data analysis workflows includes:

[0028] The process definition module is used to declare a corresponding step scope for at least one executable step in the process in the process control file, and associate a default configuration with each step scope; the default configuration type includes empty configuration, inherited configuration or control configuration;

[0029] The command parsing engine is used to: receive and parse command line input, identify scope identifiers within it; bind command line arguments to the step scopes specified by the scope identifiers; and apply default configurations associated with the process definition module for step scopes not specified in the command line.

[0030] The process execution engine is used to schedule and execute each step of the data analysis process based on the structured configuration mapping generated by the command parsing engine.

[0031] By adopting the above technical solution, the present invention has at least the following beneficial effects:

[0032] 1. Seamless isomorphic interaction between CLI and GUI is achieved: Since the GUI form is generated entirely based on the definition of the step scope, and the form fields correspond one-to-one with the scope identifiers and parameters in the command line, the parameters filled in by the user through the GUI can be directly concatenated into a single-line CLI command conforming to this invention, and vice versa. This eliminates the intermediate layer in the prior art where GUI configurations need to undergo complex conversions before being recognized by the CLI engine, greatly reducing the mental burden and usage cost for users switching between the two interaction modes.

[0033] 2. Eliminates the dependency on additional configuration files: The configuration information of this invention is fully embedded in the command-line syntax and process definition script, eliminating the need for separate XML, JSON, or YAML configuration files to define steps and parameter mappings. This simplifies the system architecture, reduces the maintenance overhead of configuration synchronization, and avoids the patent infringement risks that may arise from using generic configuration file formats.

[0034] 3. It provides a consistent, concise, and powerful process configuration interface: users only need to master one set of scope-based parameter rules to simultaneously master efficient command-line writing and intuitive graphical interface operation. For developers and the platform, there is no need to maintain two separate sets of configuration logic for CLI and GUI, unifying the technology stack and improving development and operation efficiency.

[0035] 4. This invention ensures the determinism and consistency of parameter parsing results and avoids configuration conflicts by using the principle of unique parameter name binding and the rule of priority for first appearance. Attached Figure Description

[0036] Figure 1 This is a flowchart of the method for unified expression of multi-step parameters of single-line commands based on scope marking and isomorphic linkage with GUI according to the present invention;

[0037] Figure 2 This is a system block diagram illustrating the unified expression of multi-step parameters in a single-line command based on scope marking and its isomorphic linkage with the GUI, as an example. Detailed Implementation

[0038] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0039] This invention provides a method for unified expression of multi-step parameters in a single-line command based on scope marking and isomorphic linkage with a GUI. Its core lies in establishing a parsing and execution paradigm based on scope marking, following the design principles below:

[0040] 1) Unique parameter name binding and first occurrence priority principle:

[0041] To achieve determinism and unambiguity in parameter parsing, the parser of this invention follows the principle of unique parameter name binding. Specifically:

[0042] When parsing a single command, regardless of whether the parameter appears in global form (--parameter name value) or within a specific scope (@scope: --parameter name value), as long as their parameter identifiers (parameter names) are the same, they are considered to be assignments to the same configuration item.

[0043] The system uses a first-occurrence priority rule: only the value assigned to the parameter name the first time it appears in the entire command is adopted, and all subsequent attempts to assign values ​​to the same parameter name are automatically ignored. For example, for the command `mypipeline --foo 1 @foo: --bar 2 @: --foo 3`, the final value of the parameter `foo` after parsing is still 1, the first occurrence. This principle fundamentally prevents logical conflicts that may result from duplicate parameter definitions, ensuring the uniqueness and predictability of the configuration results.

[0044] 2) Flexible default value declaration and inheritance mechanism:

[0045] In the process definition steps, a default configuration is preset for each step scope through a specific declaration syntax. This mechanism greatly improves the flexibility and simplicity of configuration. The default configurations are mainly divided into two types:

[0046] Default values ​​for constants: For example, the declaration ::@step1=0:: indicates that if the command line does not provide any parameters for the step1 scope, the parameter set associated with that scope will be treated as the value 0 by default. This setting can be used to control whether the step is executed.

[0047] Dynamically referencing default values, or inherited configurations, achieves parameter inheritance by referencing names from other scopes. For example:

[0048] ::@step1=@global1:: indicates that the scope of step1 inherits the value of the global parameter global1 by default.

[0049] ::@step1=@step2:: indicates that the scope of step1 inherits the complete parameter configuration of the other step scope step2 by default.

[0050] ::@step1=@'':: indicates that the default value is an empty string, that is, no parameters are passed. This setting is equivalent to an empty configuration.

[0051] This inheritance mechanism allows process developers to establish dynamic parameter relationships between steps and between steps and the global context, significantly reducing the number of parameters that users must explicitly enter in the command line.

[0052] 3) Isomorphic interaction design between CLI and GUI

[0053] The parameter scoping mechanism of this invention naturally constitutes a unified data model for CLI and GUI. The GUI can dynamically generate corresponding parameter configuration forms directly based on the step scopes declared in the process definition. Each input field in the form corresponds strictly one-to-one with the scope identifier and its internal parameters in the command line. Therefore, after the user fills out the form in the GUI, the front end can seamlessly concatenate it into a single command line string conforming to the above syntax rules; conversely, any valid command line configuration can also be accurately restored to the form state in the GUI. This achieves essential unification of the two interaction modes at the data and logic levels.

[0054] Example 1: The following example uses the data analysis workflow mypipeline, which consists of three sequentially executed steps: Step A, Step B, and Step C, to fully demonstrate the implementation process of this invention. Figure 1 As shown:

[0055] S1. Process definition, implemented through a process control script file:

[0056] The developer writes the main control script `mypipeline`, and uses the syntax of this invention at the top of the script to declare the default behavior of the scope of each step:

[0057] ::@StepA=@''::

[0058] This indicates that StepA's default configuration is empty, meaning that when no additional parameters are specified, StepA's own internal default values ​​are used.

[0059] ::@StepB=@StepA::

[0060] This indicates that StepB's default configuration is inherited, meaning it inherits all parameter settings from StepA, such as using the same dataset ID.

[0061] ::@StepC=0::

[0062] This indicates that StepC's default configuration is a control configuration, and a value of 0 means that this step is not executed by default.

[0063] Command-line CLI invocation: Users invoke the above process via a single command line, providing customized parameters for different steps. Based on the process script definition, users can construct commands such as:

[0064] mypipeline --input data.txt --verbose true \

[0065] @StepA: --filter low --format csv \

[0066] @StepB: --threshold 0.8 \

[0067] @: --output result.csv

[0068] in:

[0069] --input data.txt --verbose true is a global parameter that applies to the entire process and is used to specify the input file and debugging options;

[0070] @StepA: ...Introduces the StepA scope, whose two parameters --filter low and --format csv override StepA's default configuration;

[0071] @StepB: ...Introduces the StepB scope, providing only the --threshold 0.8 parameter. According to the default declaration @StepB=@StepA::, StepB will inherit the --filter low and --format csv parameters of StepA;

[0072] @: Ends the scope of StepB and returns to the global scope;

[0073] --output result.csv is a subsequent global parameter.

[0074] In this step, a single command clearly expresses the configuration for each step: Step A uses low filtering and CSV format; Step B uses a threshold of 0.8 and inherits the relevant settings from Step A; Step C is not explicitly given, so it is set according to the default value of 0. This step can be skipped, or the program can decide whether to skip it. Compared to traditional methods, this method eliminates the need for users to prepare multiple commands or configuration files to complete complex process configurations, greatly improving efficiency.

[0075] S2. Command Parsing: After receiving the above command, the mypipeline script parses it. The specific parsing process is as follows:

[0076] S21. Scan the parameter list, identify the "@scope:" marker and construct the corresponding scope object. For example, when "@StepA:" is encountered, a StepA configuration object will be created, and subsequent parameters such as "--filter low --format csv" will be assigned to this StepA object until the next "@Step...:" or "@:" marker is identified.

[0077] S22. Parameter binding is handled according to the "first occurrence first" rule. For example, if input has been set to data.txt when parsing global parameters, even if a parameter with the same name as the global parameter appears again in the "@StepA:" scope, but this does not occur in this example, the previous parameter binding will not be overwritten, thus avoiding conflicts between parameters at different levels. After the command is parsed, a structured configuration mapping will be generated, as shown in the following pseudocode:

[0078] {

[0079] "input": "data.txt",

[0080] "verbose": true,

[0081] "StepA": {"filter": "low", "format": "csv"},

[0082] "StepB": {"threshold": 0.8},

[0083] "output": "result.csv"

[0084] }

[0085] For StepC that is not provided, "StepC": 0 will be obtained according to the default value rule, or it will be marked as not to be executed.

[0086] S3. Process Execution: Based on the parsing results of step S2, the script executes each step sequentially, as follows:

[0087] StepA is executed using the parsed StepA parameters {"filter": "low", "format": "csv"}. If it is empty, the default is used.

[0088] StepB is executed using the inherited and overridden {"threshold": 0.8, "filter": "low", "format": "csv"};

[0089] Step C is skipped because its configuration value is 0. The final result is output to result.csv; the results of each step are aggregated and finally output to the globally specified result.csv file.

[0090] S4. Interface Generation: In this step, the same mypipeline process can be presented in the GUI. The backend, based on the scopes of the three steps StepA, StepB, and StepC defined at the top of the script, drives the frontend to dynamically generate three independent parameter forms.

[0091] The StepA form contains filter and format fields;

[0092] The StepB form includes a threshold field, and because it inherits from StepA, the interface can provide suggestions or automatically fill in filter and format values ​​from StepA.

[0093] The StepC form can be presented as an enable / disable option.

[0094] After the user fills out a form in the GUI and clicks "Run," the front-end logic directly concatenates the form values ​​into a command-line string as shown in the CLI above, and then sends it to the back-end for execution. Every field seen by the user in the GUI form corresponds precisely to a specific parameter in the command line, achieving a "what you see is what you get" and consistent operation.

[0095] Through Example 1, the specific application of the core mechanism of the present invention and the following advantages it demonstrates in application can be clearly seen:

[0096] 1) It has the characteristic of single-source fact. The GUI and CLI are based on the same semantic source and do not rely on external configuration translation layer. Specifically, the command string is used as the only semantic source. The parsed parameter mapping tree supports both process execution and GUI restoration. There is no need to maintain external configurations such as YAML / XML / DSL. This not only eliminates the configuration drift problem, but also requires only one change for version updates. It can also generate a "process snapshot" by hashing the command. Ultimately, this is reflected in a significant decrease in detectable indicators such as the number of maintenance points for the same process, the number of human-computer interaction steps for release changes, and rollback time.

[0097] 2) Deterministic and auditable characteristics: Through the unique binding specification of "first occurrence first" combined with the parsing normalization mechanism, the position, original value and timestamp of conflict and ignored values ​​are recorded. This ensures that the same input command can parse the same parameter tree on different hosts and at different times. The source of conflict can be located by replaying based on the audit log. This achieves 100% consistency of parameter trees when the same command is executed N times and reduces the average time for conflict location. The unique binding principle of parameter name is the core embodiment of this characteristic, which ensures that the parsing of all global and scope parameters in the mypipeline command is deterministic and conflict-free.

[0098] 3) Backend-independent feature: Treating container / scheduling backend as ordinary parameters or tags, the parsing phase is not bound to a specific platform. It is only distributed through the adaptation layer during the execution phase, which allows mypipeline to switch freely between Docker / Podman / Apptainer or bare metal without changing the command semantics. This ensures that the same command executes with consistent results on different backends and the number of lines modified during migration is almost zero, greatly enhancing the portability of the process.

[0099] 4) Low learning and maintenance costs: The parameter hierarchy is expressed through a common "--flag value" format combined with a few scope notations. The GUI directly fills in the same parameter structure without the need to learn additional DSLs. In mypipeline, the application of default values ​​and inheritance mechanisms is achieved by declaring StepB as @StepB=@StepA::, allowing StepB to automatically inherit the filter and format configurations of StepA. This greatly simplifies commands, ultimately enabling new users to directly copy and paste commands between the GUI and CLI, and reducing the configuration editing burden for experienced users. This significantly reduces learning time, document pages, and common error rates. The CLI / GUI isomorphic design is also fully demonstrated in this process: GUI forms are generated driven by scope definitions and can be converted to CLI commands without loss of quality, fully verifying the feasibility and superiority of this invention in a real system.

[0100] This embodiment also provides a parameter management system for a configurable data analysis workflow, which includes:

[0101] The process definition module is used to declare a corresponding step scope for at least one executable step in the process in the process control file, and associate a default configuration with each step scope; the default configuration type includes empty configuration, inherited configuration or control configuration;

[0102] The command parsing engine is used to: receive and parse command line input, identify scope identifiers within it; bind command line arguments to the step scopes specified by the scope identifiers; and apply default configurations associated with the process definition module for step scopes not specified in the command line.

[0103] The process execution engine is used to schedule and execute each step of the data analysis process based on the structured configuration mapping generated by the command parsing engine.

[0104] Based on the aforementioned parameter management system, this embodiment also provides a system for unified expression of multi-step parameters in single-line commands based on scope marking and isomorphic linkage with the GUI, such as... Figure 2 As shown, it includes: two process definition modules, two command parsing engines, and one process execution engine;

[0105] The two process definition modules are a CLI process definition module and a GUI process definition module. The CLI process definition module is used to declare the corresponding step scope for CLI steps and associate a default configuration with each step scope. The GUI process definition module is used to declare the corresponding step scope for GUI steps, wherein the step scope is a form structure and a default configuration is associated with each form structure.

[0106] The two command parsing engines are a CLI command parsing engine and a GUI isomorphic module, respectively. The command parsing engine receives and parses CLI single-line commands provided by the CLI process definition module, identifies the scope identifier in the CLI single-line command, binds command-line parameters to the step scope specified by the scope identifier, associates the default configuration with the step scope not specified in the command-line parameters, and generates a structured configuration mapping after parsing. The GUI isomorphic module generates a form based on the form parameters, uses the common "--flagvalue" format combined with a small number of scope notations to express the parameter hierarchy, and directly backfills the same parameter structure through the GUI.

[0107] The process execution engine is used to schedule and execute based on the parsing results of the two command parsing engines. After being adapted by the backend adaptation module, it outputs the execution results or logs.

[0108] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for unified expression of multi-step parameters in a single-line command based on scope marking and isomorphic linkage with a GUI, used for parameter management of configurable multi-step processes, characterized in that, Includes the following steps: S1. Process Definition: In the process control file, Declare a corresponding step scope for at least one executable step in the process; and associate a default configuration with each step scope; the default configuration includes at least one of the following types: a) Empty configuration, used to indicate that the step uses its own internal default parameters; b) Inherited configuration, used to indicate that this step inherits the configuration from another specified step scope; c) Control configuration, used to indicate the execution status of this step; S2. Command Parsing: Receives command line input containing parameters and scope identifiers. Based on the scope identifier, identifies the explicitly enabled step scope in the command line and binds the parameters located after the scope identifier until the next scope identifier or the scope terminator to the corresponding step scope. For step scopes not explicitly enabled in the command line, the default configuration associated with them in step S1 is applied. The first occurrence priority rule is used to handle parameters with the same name at different levels. S3. Process Execution: Based on the structured configuration mapping parsed from S2, execute each step of the process sequentially, where each step runs using parameters bound to its step scope; S4. Interface Generation: Based on the step scope defined in step S1, generate the parameter configuration form for the corresponding step in the graphical user interface; wherein, the input fields of the GUI form correspond one-to-one with the scope identifier and its parameters in the command line; the user input values ​​received by the GUI form are converted into equivalent command line parameters containing the scope identifier.

2. The method for unified expression of multi-step parameters of a single-line command based on scope marking and isomorphic linkage with the GUI as described in claim 1, characterized in that, In step S1, the scope of the step and its default configuration are declared through text syntax that includes setting delimiters.

3. The method for unified expression of multi-step parameters of a single-line command based on scope marking and isomorphic linkage with the GUI as described in claim 2, characterized in that, The format of the text syntax is::@step_name=default_value::.

4. The method for unified expression of multi-step parameters in a single-line command based on scope marking and isomorphic linkage with the GUI as described in claim 1, characterized in that, The inheritance configuration is indicated by explicitly writing the name of the inherited step scope.

5. The method for unified expression of multi-step parameters of a single-line command based on scope marking and isomorphic linkage with the GUI as described in claim 1, characterized in that, The control is configured as a numerical flag to indicate whether to skip the execution of this step.

6. The method for unified expression of multi-step parameters of a single-line command based on scope marking and isomorphic linkage with the GUI as described in claim 1, characterized in that, The scope identifier is in the format @step_name:, and the scope terminator is in the format @:.

7. A system for unified expression of multi-step parameters of a single-line command based on scope marking and isomorphic linkage with a GUI, used to implement the method for unified expression of multi-step parameters of a single-line command based on scope marking and isomorphic linkage with a GUI as described in claim 1, characterized in that, include: The process definition module is used to declare a corresponding step scope for at least one executable step in the process in the process control file, and associate a default configuration with each step scope; the default configuration type includes empty configuration, inherited configuration or control configuration; The command parsing engine is used to: receive and parse command line input, and identify scope identifiers within it; Bind command-line arguments to the step scope specified by the scope identifier; Apply the default configuration associated with the process definition module to the scope of steps not specified in the command line; The process execution engine is used to schedule and execute each step of the data analysis process based on the structured configuration mapping generated by the command parsing engine.

Images