Skip to content
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

Custom template methods #165

Open
chason-choate opened this issue Mar 4, 2022 · 2 comments
Open

Custom template methods #165

chason-choate opened this issue Mar 4, 2022 · 2 comments

Comments

@chason-choate
Copy link

chason-choate commented Mar 4, 2022

As we expand on our usage of mockintosh we need the ability to provide custom template methods to do more complicated actions. For instance, we have a use-case where we want to inject certain complicated structures into objects based on some conditions.

FWIW we are using the docker container and happy to build out new python methods. We just need an easy way to wire them into Mockintosh. At the moment we are mounting copies of the hbs/methods.py and templating.py files into the container with custom code.

I have limited python knowledge but i think something like the following could be useful.

  1. Mockintosh uses something to determine where to read custom methods.
    a. An env var to define where custom methods files will be read. MOCKINTOSH_TEMPLATE_METHODS_DIR.
    b. OR additional yaml configuration that specifies either a directory or specific files to load?
  2. Place the file with custom methods at that ^^ location.
  3. Each methods file will expose an inject_methods() -> list[Callable] method. These defined methods can be merged with the existing methods in the templating.py file.
@undera
Copy link
Contributor

undera commented Mar 13, 2022

Have you looked at the interceptors (https://mockintosh.io/#interceptors) ?

@chason-choate
Copy link
Author

This is, in a way, related to #164. Giving users of the service the ability to inject new template methods would be a large usability boon as they could be iterated upon within the UI editor, etc. (Their usage, I mean. The implementation could be unit tested elsewhere if needed)

I did not see interceptors previously. Good to know they exist but they feel too general for this use-case. Interceptors seem to lack the interactivity you get from editing config/templates/etc. through the UI.

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

No branches or pull requests

2 participants