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
We currently have generic handlers for parameters in the runtime package. These use either reflection or the swagger spec to generically handle any parameter.
A much better, though more difficult approach would be to generate the specific code to marshal and unmarshal each parameter from a query. We know the exact style, format and content for each parameter at generation time, so we only need a subset of the generic code to handle each, and that could be embedded without any conditional type logic where it's used.
The thought of the template code to do this, though, makes me shake with fear.
The text was updated successfully, but these errors were encountered:
I agree that the template code was too dirty to proceed with, so I've implemented it using helper-functions. It still needs some work, but let me know if this is going in the right direction because it would be great to merge this back.
I've added a new choice for the generate command-line option called "richclient", which generates this new client code instead of the existing one (as a way to maintain backwards-compatibility).
We currently have generic handlers for parameters in the runtime package. These use either reflection or the swagger spec to generically handle any parameter.
A much better, though more difficult approach would be to generate the specific code to marshal and unmarshal each parameter from a query. We know the exact style, format and content for each parameter at generation time, so we only need a subset of the generic code to handle each, and that could be embedded without any conditional type logic where it's used.
The thought of the template code to do this, though, makes me shake with fear.
The text was updated successfully, but these errors were encountered: