-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Support included blocks override #84
Conversation
This changes behavior and was never intended to be supported. However since the whole scoping is something I want to overhaul I will decide in neither way right now and try to find a solution that is compatible with the current behavior and would support blocks be defined in included templates. |
How is the proposed patch not compatible with the current behavior? |
I would love to be able to override blocks like this. |
I merged this now. I don't see how this breaks anything currently. |
This provides a basic jinja2 static template that demonstrates the breaking behavior introduced by pallets/jinja#84.
@mitsuhiko - This change breaks a few websites that use hyde. Here is a simple demo: Pushing parent blocks along with other context variables is surprising IMO. I'd like to propose:
or something similar instead if its not too late. Edit: Here is (hopefully) a better statement of the bug: Given a container C and an include I, this patch really includes container C with the include I injected at the top of the extension hierarchy of C. As long as I and C have completely different set of blocks this is okay. However, when there is an overlap between the blocks of I and C, the results will likely be surprising(bad). |
I think its safer to completely pull this change out and reintroduce it only if a block resolution order can be provided alongside. |
To add to this, this update seem to break my site badly (unless I'm doing something else wrong of course...) I have three template files, A, B and Base.
This throws me in maximum recursion, as (if I understand it correctly), in A.content we include B.content which was defined in A.content and so on? I had the same structure which was not an issue before, I presume before this update the block content in the included template was simply ignored? I can include without context but that will break other things, e.g. not being able to pass my model objects down to the included templates. |
Will this feature be revived? Would be very happy to see this. The lack of this feature is the only issue I have had so far with Jinja2. |
This commit fix inheritance with included blocks.
Consider these templates:
A.jinja2
I.jinja2
B.jinja2
As of now, rendering B.jinja2 would output:
This patch allow B to override I block, the output will be instead: