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
One of the features the library supports is for the case when you use {% includes %} or {% extends %} you can create context for the included/extended template that is consistent regardless of how it's used - so that you can define defaults for EG a button in one place and then every time you include the button in a component you get the same defaults, unless you override them. An example would be that you'd have two templates - parent.jinja and child.jinja, and two yaml files, parent.yaml and child.yaml, that could specify hard coded variables to allow the templates to render in a static context. parent.yaml could specify a few variables, and child.yaml could potentially overwrite parent's variables.
that seems really hard to do with Jinja and I'd love a little advice on how to approach it - it seems like extending the parser and the include/extends nodes is a non starter, so I'm thinking I could make an extension that uses those tags? That it possible to shadow a built in tag w/ an extension?
I think I could ask people to install the extensions in their project as part of initial setup, so I don't need to get access to the jinja_env directly, but because this is a development tool it's not going to work to add much to the templates themselves.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm trying to extend https://github.com/torchbox/django-pattern-library to have jinja support - I have a rough version working (https://github.com/gone/django-pattern-library/tree/jinja) that does the base case of rendering a template in isolation with some generated context ( either through yaml or through a function you register with a decorator)
One of the features the library supports is for the case when you use {% includes %} or {% extends %} you can create context for the included/extended template that is consistent regardless of how it's used - so that you can define defaults for EG a button in one place and then every time you include the button in a component you get the same defaults, unless you override them. An example would be that you'd have two templates - parent.jinja and child.jinja, and two yaml files, parent.yaml and child.yaml, that could specify hard coded variables to allow the templates to render in a static context. parent.yaml could specify a few variables, and child.yaml could potentially overwrite parent's variables.
The library does that by shadowing the django template include/extends tags and injecting some custom logic: https://github.com/torchbox/django-pattern-library/blob/main/pattern_library/loader_tags.py - they check to see if the current render is inside the pattern lib, and if so load out the external variables and injext those into the context.
that seems really hard to do with Jinja and I'd love a little advice on how to approach it - it seems like extending the parser and the include/extends nodes is a non starter, so I'm thinking I could make an extension that uses those tags? That it possible to shadow a built in tag w/ an extension?
I think I could ask people to install the extensions in their project as part of initial setup, so I don't need to get access to the jinja_env directly, but because this is a development tool it's not going to work to add much to the templates themselves.
Beta Was this translation helpful? Give feedback.
All reactions