Repository navigation
Put all UI related parameter options in metadata #3
Description
In the current spec all UI related options of computation template parameters are in the json object. Like the in the rest of the spec all ui related stuff should be placed in a metadata sub property, so it's simply to filter these options in the websocket-api and keep the websocket api independen of any new added option.
Only the validation should not be in the metadata of the parameter, because it's used by the websocket-api to validate the user input. The validation property of the parameter should not be a string but rather an object which contains all the validation settings, that are currently spread across the parameter object.
I don't understand the difference between oneof and anyof.
It's not defined how a "numeric value" is defined for range. Because to check the range the "number" needs to be parsed. Which formats are allowed, int, float, "." or "," as separator? We should keep this validation on the server side simple, so we have not to deal with programming language specific formats.
Activity
Legion2 commentedon May 9, 2020
I will update the websocket implementation with the parameter valdiation
Legion2 commentedon May 9, 2020
The parameters of the file part with access "template", should be elements of a
parametersproperty, so there is no name collision with other metadata. Currently the parameters are defined as direct childs of the metadata:metadata --PARAM_IDpascalseeland commentedon May 10, 2020
We had a discussion on this issue before writing the specification this way. We opted for having it flat as we did not see a clear way of separating the information required for validation and the ui. E.g. both, validation and UI need the information about the step, min, max or the possible values for a drop-down list. It we felt it seems wrong if e.g a dropdown list in the front-end needs to get a its values from a validation-object
Legion2 commentedon May 10, 2020
The information could be "duplicated", so when creating UI elements, the UI representation is stored in the metadata and the validation (maybe in a different format) is stored in
validation. Only the UI which creates new parameter must know how to do UI and validation all other parts of the system either require the metadata or the validation.Legion2 commentedon May 10, 2020
How is the parameter value format if multiple values are selected. Is is a comma separated list? Are the entries of the list escaped or encoded?
Legion2 commentedon May 10, 2020
Is there are limit how big the numbers can be, are the numbers int32 or int64 / float32 or float64? Do we support numbers like
1.5e-15, such numbers are supported by JSON?Merge pull request #3 from pascalseeland/params