-
Notifications
You must be signed in to change notification settings - Fork 225
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
Using blocks more than once? #158
Comments
@NocturnalSolutions I have a solution for that but I'm not sure it's a right way to use blocks. In your example imagine that you will change If I understand correctly in your case you are using blocks as a placeholders for something that is defined in extended templates. But I think blocks were originally designed to support another use case - extending their content in extended templates. @kylef what do you think about that? Here is the change that will fix this issue. Here I'm pushing back already rendered node from extended template so that it can be used again by base template. All tests are passing but maybe we are missing some edge case where it can lead to infinite recursion. diff --git a/Sources/Inheritence.swift b/Sources/Inheritence.swift
index b9bf87a..4f37022 100644
--- a/Sources/Inheritence.swift
+++ b/Sources/Inheritence.swift
@@ -129,6 +129,7 @@ class BlockNode : NodeType {
func render(_ context: Context) throws -> String {
if let blockContext = context[BlockContext.contextKey] as? BlockContext, let node = blockContext.pop(name) {
+ defer { blockContext.push(node, forKey: name) }
let newContext: [String: Any] = [
BlockContext.contextKey: blockContext,
"block": ["super": try self.render(context)] |
Actually tests do fail with this change, so I'm even less sure about it. |
Jinja2 solves this this way:
We can do something similar, i.e. by storing all blocks in |
Requiring new syntax just for printing a block a second time, while better than nothing, still strikes me as odd, though. Why can't I just use the same syntax in both places? Am I really that odd for wanting/expecting this? Aside from the example I give in the OP of repeating a title both in Yes, I can work around this by using variables, but there are cases where that would clearly break the concept of code/design separation I'm supposed to gain by using a template engine. Perhaps there are other workarounds I could use that I haven't discovered yet, but what I'm hoping for in the OP seems to me to be the simplest solution from the perspective of the template author. |
@NocturnalSolutions I tried to explain in my previous comment why the same syntax can't be used in the way you want it, it creates ambiguity in inheritance. The syntax that is used to define a block can't be the same as syntax used to call this block later, the same way as syntax for defining and calling functions are different in programming languages. |
@NocturnalSolutions Doesn't a variable make more sense here?
The only difference is that you specify the value in your rendering context, not on the page itself. I do something like that in https://github.com/svanimpe/swift-blog. |
Sure, that works in that case. But what about the more complex example I put in my OP of a pager you want to appear at both the top and bottom of a page? I suppose as a workaround you could render a template to a string that you then use as a variable. I still think just being able to reuse blocks would be a more pleasant solution, though. |
In your OP, the content of block I view blocks as something similar to method overrides with subclassing. That is: you define a default in the parent, and optionally override it in a child. So not simply reusable blocks. I think that's what the include tag is for. |
layout.stencil:
hello.stencil:
So my ideal result would be:
I think this is a natural way to have a "subtitle" that appears both in the page content and in the
<title>
tag, but it doesn't seem to work - the secondpageTitle
block isn't filled in. So the result looks like:Not sure if this counts as a bug. If not, please consider it a feature request.
The text was updated successfully, but these errors were encountered: