Project Frontend
2.1K
Enables creation of graphical queries on CSV data.
Docker Hub: qub40232046/40232046-graphical-processing-fe
docker run -d -p 3000:3000 qub40232046/40232046-graphical-processing-fe:{tag}
This will use the default configuration, which is intended for use with the paired backend.
The default URL is localhost:8080 for the backend.
docker run -d -p 3000:3000 -e REACT_APP_BACKEND="{url}" qub40232046/40232046-graphical-processing-fe:{tag}
Note:REACT_APP_BACKEND variable only needs to be supplied to override backend specified in config file.
docker run -d -p 3000:3000 --volume={config path}/config.json:/app/src/config.json qub40232046/40232046-graphical-processing-fe:{tag}
Refer to Configuration section for more details on how to create custom configurations.
Two node options are hard coded into the frontend due to their core importance to the implementation.
There are a list of default nodes broken down to a reasonable extent for purpose of integration with the backend referenced at the top.
An example operation configuration might be as follows:
{
"operation": "testOp",
"name": "Test Operation",
"template": {
"operation": "backendOperationName",
"specificOperation": "testOp",
"textFieldName": null,
"numericFieldName": null,
"integerFieldName": null,
"dropdownFieldName": "first",
"switchFieldName": true,
"nonUserEditableField": "unchangeable value",
"expectedInputs": 2
},
"textFieldName": {
"input": "text",
"title": "Text Field Name",
"width": "100%",
"required": true
},
"numericFieldName": {
"input": "numeric",
"title": "Numeric Field Name",
"width": "100%",
"required": true
},
"integerFieldName": {
"input": "integer",
"title": "Integer Field Name",
"width": "100%",
"required": true
},
"dropdownFieldName": {
"input" : "dropdown",
"title": "Dropdown Field Name",
"width": "100%",
"required": true,
"options": [
"first",
"second",
"third"
]
},
"switchFieldName": {
"input": "switch",
"title": "Switch Field Name",
"width": "100%",
"required": true
}
}
Visible in the example are each of the possible options regarding a field.
As seen above, a field which is intended for user input will be configured by an object value under its name as key.
If no key is present for configuration by the user, it is assumed the value it is given in the template is what is to be sent to the backend.
An example of this is "nonUserEditableField".
Text fields offer the following configurability:
An example of this is "textFieldName".
Validation of text fields is non-empty string presence and is carried out onBlur of the input.
Numeric fields offer the following configurability:
An example of this is "numericFieldName".
Validation of numeric fields is number presence and is carried out onBlur of the input.
Integer fields offer the following configurability:
An example of this is "integerFieldName".
Validation of integer fields is integer presence and is carried out onBlur of the input.
Dropdown fields offer the following configurability:
An example of this is "dropdownFieldName".
Validation is unnecessary on this field.
Switch fields offer the following configurability:
An example of this is "switchFieldName".
Validation is unnecessary on this field.
There are 3 levels of queries which you can save, and load back in for future use.
This will save a valid graph in its entirety, files and all. Useful for repetition of exact query at a later stage. Loading this graph in will produce a processable query immediately.
This will save a valid graph for all but its input files. Useful for queries which need to run periodically with
simply input data changing.
Loading this graph will mean Open File nodes are invalid, as they need files supplied. Once they are, the graph will
be processable.
This will only save the node operations, and the flow of data indicated by edges.
The configuration of the nodes and supplying of the data files will need to be carried out after loading the graph.
Content type
Image
Digest
Size
369.2 MB
Last updated
over 4 years ago
docker pull qub40232046/40232046-graphical-processing-fe