dustjs
dustjs copied to clipboard
Add support for parameters on inline partials/blocks
This adds support for passing parameters/attributes to inline partials/blocks. This change will cause inline partials to act almost exactly the same passing parameterss to a section or (non-inline) partial (wrt setting and passing parameters).
I've added tests for three use-cases, but am happy to add to or remove them if you think a different test would be more expressive of this change. Also, note, all tests are passing locally.
Below are a few more examples of how parameters on inline partials will work after this PR:
{! JSON: {"search_url": "http://google.com/search"} !}
{<partial}
Partial url is: {url}
{/partial}
{+partial url=search_url/}
Outputs: Partial url is: http://google.com/search
{<partial}
Partial url is: {url}
{/partial}
{+partial url="http://google.com/search"/}
Outputs: Partial url is: http://google.com/search
{! JSON: {"url": "http://google.com/search"} !}
{<partial}
Partial url is: {url}
{/partial}
{+partial/}
Outputs: Partial url is: http://google.com/search
{<partial}
Partial url is: {url}
{/partial}
{+partial url=nonExistentRef/}
Outputs: Partial url is:
{! JSON: {"search_url": { "value: "http://google.com/search" } } !}
{<partial}
Partial url is: {url.value}
{/partial}
{+partial url=search_url/}
Outputs: Partial url is: http://google.com/search
{! JSON: {"url": "http://google.com/search" } !}
{<partial}
Partial url is: {url}
{/partial}
{+partial url=search_url/}
Outputs: Partial url is: http://google.com/search
{! JSON: {"url": "http://google.com/search" } !}
{<partial}
Partial url is: {.url}
{/partial}
{+partial url=search_url/}
Outputs: Partial url is:
Thanks and let me know if I need to update any READMEs or wikis anywhere.
Can you give a real use case, because the way I use blocks is one base template which contains the blocks and sub templates that include that base template and override those blocks such as:
base.tl
{<content
Here is my content {content}
/}
article.tl
{>"base" content="awesome content"/}
{+content/}
So basically my question is if the above solves all use cases, or if there is a use case where you can't just pass parameters to a base template(since there may not be one for ex).
lgtm, let's get another pair of eyes on it.
Looks like you need to git pull
before we try to merge.
Does this work with two separate partials?
{! base.tl !}
{+partial url=search_url/}
{! override.tl !}
{>"base.tl"/}
{<partial}
Partial url is: {url}
{/partial}
My concern is that the blocks are added as global(ish) variables at the partial level. Since these are different partials, will the params be added to the correct context?
Also, what happens if the inline partial is within a different context than the block?
{+partial url=search_url/}
{#myOtherContext}
{<partial}
Partial url is: {url}
{/partial}
{/myOtherContext}
I'm guessing that this won't work.
See #313 This will be inconsistent with how params are treated in sections and partials when there is a conflict.