Skip to content
This repository has been archived by the owner on Sep 6, 2023. It is now read-only.

Add support for a default parameter config #48

Closed
shonfeder opened this issue May 26, 2020 · 3 comments
Closed

Add support for a default parameter config #48

shonfeder opened this issue May 26, 2020 · 3 comments
Milestone

Comments

@shonfeder
Copy link
Contributor

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.

@shonfeder shonfeder changed the title Add support for a "default config" Add support for a default parameter config May 26, 2020
@thanethomson
Copy link
Member

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.

@shonfeder
Copy link
Contributor Author

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?).

Agreed.

@thanethomson
Copy link
Member

Implemented as per #23 (currently on branch prototype/v2, soon to be merged to master).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants