diff --git a/js/test_cases/explicit_context_setting/README.md b/js/test_cases/explicit_context_setting/README.md index 3928dd0..d0ea503 100644 --- a/js/test_cases/explicit_context_setting/README.md +++ b/js/test_cases/explicit_context_setting/README.md @@ -17,7 +17,7 @@ Explicitly setting a context in a partial also works. The explicit context takes This works for both regular named partials and quoted partials. -While normally parameters are injected 1 level above the current context, if both parameters and explicit are set, they are injected below the current context. So if the context tree was `1->2->3`, with just parameters you'd have `1->2->parameters->3` but with an explicit context you have `1->2->3->parameters->explicit`. +While normally parameters are injected 1 level above the current context, if both parameters and explicit are set, they are injected below the current context. So if the context tree was `1->2->3`, with just parameters you'd have `1->2->parameters->3` but with an explicit context you have `parameters->explicit`. Helpers ------- @@ -31,6 +31,8 @@ Explicitly setting a context on an inline partial does not work, but it does not Explicitly setting a context on a block does work. +The explicit context for inline partials is evaluated in the context for that template file containing the block, not the inline partial (so, whatever the context is when we invoke the partial containing the block). + References ---------- diff --git a/js/test_cases/explicit_context_setting/explicit_evaluation_time.dust b/js/test_cases/explicit_context_setting/explicit_evaluation_time.dust new file mode 100644 index 0000000..704b614 --- /dev/null +++ b/js/test_cases/explicit_context_setting/explicit_evaluation_time.dust @@ -0,0 +1,6 @@ +{#block} + {+pet_line}BLOCK: {contents}{~n}{/pet_line} +{/block} +{#inline_partial} + {explicit_evaluation_time_split_default/} +{/block.message} +{other_friend:explicit friend="Dave" pet="rabbit"/} {/loop} +{! Is an explicit context on an inline partial evaluated in the context of the block or the context of the inline partial? !} +Explicit Evaluation Time Global{~n} +==============================={~n} +{>explicit_evaluation_time/} + +Explicit Evaluation Time Partial Context{~n} +========================================{~n} +{#partial_context} + {>explicit_evaluation_time/} +{/partial_context} + +{! The previous test discovered that the inline partial's explicit context is evaluated based on the context when invoking the full-blown partial, HOWEVER, it shared the same partial context for both the block and the inline partial. To conclusively prove if the explicit context is evaluated on the inline partial and not the block, we need a different partial context for each one. !} +Explicit Evaluation Time Split Partial Context Default{~n} +======================================================{~n} +{#partial_context} + {#block.message} + {>explicit_evaluation_time_split_default/} + {/block.message} +{/partial_context} + +Explicit Evaluation Time Split Partial Context OVerride{~n} +======================================================={~n} +{#partial_context} + {#inline_partial} + {>explicit_evaluation_time_split_override/} + {/inline_partial} +{/partial_context} diff --git a/src/renderer/renderer.rs b/src/renderer/renderer.rs index c3537a6..86f2e98 100644 --- a/src/renderer/renderer.rs +++ b/src/renderer/renderer.rs @@ -314,6 +314,7 @@ impl<'a> DustRenderer<'a> { } DustTag::DTInlinePartial(_named_block) => { // Inline partials are blank during rendering (they get injected into blocks) + // TODO: We will need to support explicit contexts for inline partials. return Ok("".to_owned()); } DustTag::DTBlock(named_block) => { @@ -660,6 +661,7 @@ impl<'a> DustRenderer<'a> { Some(_) => Vec::with_capacity(3), None => breadcrumbs.clone(), }; + // TODO: Can sections have parameters, and if so, what happens then? Currently when there is an injected context or an explicit context it gets inserted behind the current context, so 1->2->3 becomes 1->2->injected->3 or explicit->3. When there is a new context(4) with injected we're doing 1->2->3->injected->4. When there is an explicit context and a new context we're doing explicit->4. But what happens if there is a section with parameters and an explicit context, hitting all the categories? Would it be parameters->explicit->4? I would definitely have to change the parameters to this function since right now iteration variables and parameters are both sharing injected_context. injected_context.map(|ctx| { // Special case: when there is no explicit context or new // context element, the injected context gets inserted 1