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
In our applications, we are aiming to use fully qualified keywords whenever possible, to reduce ambiguity in data.
Martian contributes to attaining this goal, by allowing API request keys in kebab form, via the :parameter-aliases mechanism, lowering the impedance mismatch between the data structures of external data sources and Clojure programs internal nomenclature.
While this :parameter-aliases mechanism seems to be an internal API, since its structure is not explained, I assumed it might be customisable on a per-handler basis, but the automatically generated aliases override the custom ones.
Yes, I am in favour of letting data flow through and for any 'enriching' to be additive and not destructive, so what you propose sounds good. If you make a PR, there is a spec at https://github.com/oliyh/martian/blob/master/core/src/martian/spec.cljc describing the martian input data structure, you'll need to update that to include the :parameter-aliases key.
Problem
In our applications, we are aiming to use fully qualified keywords whenever possible, to reduce ambiguity in data.
Martian contributes to attaining this goal, by allowing API request keys in kebab form, via the
:parameter-aliases
mechanism, lowering the impedance mismatch between the data structures of external data sources and Clojure programs internal nomenclature.While this
:parameter-aliases
mechanism seems to be an internal API, since its structure is not explained, I assumed it might be customisable on a per-handler basis, but the automatically generated aliases override the custom ones.or more specifically:
Solution
I can introduce a custom interceptor, which would also do this kind of aliasing, but if
martian.core/enrich-handler
would be modified as follows:then, in the example above, the per-handler, custom, namespaced aliases would be retained:
@oliyh, would you consider incorporating such a change or is it a bad idea, to piggyback this feature for providing handcrafted aliases?
The text was updated successfully, but these errors were encountered: