You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
would overwrite property1 and property2 in aclimatise's internal representation of parameter1. A simple example would be to overwrite help text, default values, file types.
With an appropriate 'encoding' also the parameter type might be changed:
{
'parameter1': {
'--TYPE--': 'CliFloat'
},
...
}
could overwrite aclimatise's (wrong) guess of the parameter type (I suggest to use -- prefix since this should be an impossible name prefix).
In this way also hardcoding parameters, or removing parameters could be done via special parameter classes, e.g. CliHardcoded, CliNull (I try not to use the term blacklist here).
In the same way (with separate json files) also properties in the generated languages would be possible. Eg. a json file like the first exampe might overwrite/add attributes 'property1' and 'property2' of the xml tag with name="parameter1".
The text was updated successfully, but these errors were encountered:
So there are really two tasks here. One is adding to the data model the concept of fixed values, because it currently assumes all inputs are variables. This would involve adding fields to my Type classes. And the second point is adding a "patch" mechanism to edit the Command representation. Your examples of "changing the type to a Float", and "setting the value of this parameter to 2" are just examples of the more flexible ability to patch the data model. For this, I propose something like python-json-patch, which could be used to patch the data model.
The main problem I forsee with this is that I think python-json-patch assumes that we're working with dictionaries and lists, ie objects you can [] index, but since the data model (ie a Command instance) involves dataclasses, it may not work. Maybe that functionality exists in the library, but if not then we look for a similar but compatible library, or we make a dataclass subclass that implements the "container" methods: https://docs.python.org/3/reference/datamodel.html#emulating-container-types, or we convert to a dict temporarily, or something like that.
One might have a json file that stores curated information that helps aclimatise's parser, e.g.
would overwrite property1 and property2 in aclimatise's internal representation of parameter1. A simple example would be to overwrite help text, default values, file types.
With an appropriate 'encoding' also the parameter type might be changed:
could overwrite aclimatise's (wrong) guess of the parameter type (I suggest to use
--
prefix since this should be an impossible name prefix).In this way also hardcoding parameters, or removing parameters could be done via special parameter classes, e.g.
CliHardcoded
,CliNull
(I try not to use the term blacklist here).In the same way (with separate json files) also properties in the generated languages would be possible. Eg. a json file like the first exampe might overwrite/add attributes 'property1' and 'property2' of the xml tag with
name="parameter1"
.The text was updated successfully, but these errors were encountered: