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
{{ message }}
This repository has been archived by the owner on Sep 6, 2023. It is now read-only.
Currently, themis-contract can derive a partial (and generally malformed) configuration by extracting the parameters from a template. This saves time, but as we've seen through internal use, we really want to start working from a parameter configuration which has much more context available. The context should include information like
how to supply parameters (what kinds of types and inputs are valid)
what they default to (in case of optional parameters)
and what they mean (when self-documenting names are not feasible)
Eventually, we might be able to automate this process to some extent by inspecting the context of the passages in which the parameters appear, but this pushes us towards NLP, and such a clever solution isn't necessary and won't add much value to the current process. This is largely due to the fact that porting a contract to a parameterized template invariable involves creating an example configuration to test the port, and because the only interesting problem in such porting is modeling the domain (of which the configuration is just a representation).
To meet the immediate need and improve UI, we can make the new subcommand (and the proposed prepare#46) pull both a contract template and a default configuration (if available) from the source repo.
The text was updated successfully, but these errors were encountered:
shonfeder
changed the title
Add support for a "default config"
Add support for a default parameter config
May 26, 2020
To meet the immediate need and improve UI, we can make the new subcommand (and the proposed prepare #46) pull both a contract template and a default configuration (if available) from the source repo.
This is starting to look like we're going to eventually need a package management system for templates (e.g. what if styling and header images also need to be included with a template?).
I was trying my best to avoid this due to the complexity, but my sense is that this is the direction we're ultimately heading in.
This is starting to look like we're going to eventually need a package management system for templates (e.g. what if styling and header images also need to be included with a template?).
Currently,
themis-contract
can derive a partial (and generally malformed) configuration by extracting the parameters from a template. This saves time, but as we've seen through internal use, we really want to start working from a parameter configuration which has much more context available. The context should include information likeEventually, we might be able to automate this process to some extent by inspecting the context of the passages in which the parameters appear, but this pushes us towards NLP, and such a clever solution isn't necessary and won't add much value to the current process. This is largely due to the fact that porting a contract to a parameterized template invariable involves creating an example configuration to test the port, and because the only interesting problem in such porting is modeling the domain (of which the configuration is just a representation).
To meet the immediate need and improve UI, we can make the
new
subcommand (and the proposedprepare
#46) pull both a contract template and a default configuration (if available) from the source repo.The text was updated successfully, but these errors were encountered: