-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft: Make Context a user-implementable Trait #829
base: master
Are you sure you want to change the base?
Draft: Make Context a user-implementable Trait #829
Conversation
Provide a default find_value_by_dotted_pointer implementation based on find_value.
I'm not going to make a big change to v1 like that. What's the usecase? |
That's fair, it's a pretty big user-facing change. Could this make it into v2? I'd be happy to maintain this patchset on top of v1 in a fork for my specific usecase, until v2 comes out, but it seems like something that could be useful for others too, and having it upstreamed at some point would be very helpful. My use case is I want to proxy the variable lookups to something like {
"foo": {
"bar": "baz"
}
} In this case, a template of |
This allows implementors to return owned values.
@Keats I've added an example to showcase how this might be helpful. I'm a bit unsure what the |
bdf42a3
to
6cd9cdc
Compare
Thanks for the example. I'm not entirely sure whether this is worth adding though, you could just feed the whole env/whatever source you're getting it from to the context before rendering the template and you would have something that works just as well and that is probably faster. |
Not entirely; this would require being able to iterate over / know in advance the keys. Layered configuration crates like Figment or Config-rs don't usually give you that API, they only provide a "get" method, and for good measure. If you look at my use case above, overriding configuration with environment variables, one would have to determine all possible override variations a priori and fill them into a {
"foo": { "bar": "qux" },
"foo_bar": "qux",
"FOO_BAR": "qux",
"FOO": {"BAR": "qux"},
"FOO": {"bar": "qux"},
"foo": {"BAR": "qux"},
// all the other possible combinations
} OTOH, being able to check whether there's a matching combination when Tera encounters a variable is trivial. FWIW, |
In practice though in Tera v2, you're not going to get the json dot anymore you're going to get a bunch of ident split (eg instead of getting It seems easier to have a template function to grab from Figment/config-rs |
This adds a
ContextProvider
Trait that replaces theUserContext
and implements all methods that Tera uses to interface with theContext
. A straightforward pass-through implementation forContext
is also provided.Technically, this is a breaking change, since function signatures change, but existing code should work as-is and be specialized down to the same implementation.