| .. | ||
| default_explicit.dust | ||
| default.dust | ||
| input1.json | ||
| main.dust | ||
| other.dust | ||
| override_double_explicit.dust | ||
| override_explicit.dust | ||
| override.dust | ||
| README.md | ||
$idx and $len
$idx and $len do not survive through an explicit context setting, which will work perfectly with my injected-context architecture.
You can use $idx and $len as your explicit context, but as scalar values I do not think there is a way to access them anyway.
Exists and Not-Exists
Looks like you can exlicitly set a context with exists and not-exists tags too. This works out well in the parser because I am using the same code for those blocks.
Partials
Explicitly setting a context in a partial also works. The explicit context takes priority over the parameters in the partial tag.
This works for both regular named partials and quoted partials.
Helpers
Explicitly setting a context in a helper works too.
Blocks and Inline Partials
Explicitly setting a context on an inline partial does not work, but it does not error out either, so I need to add support for this in the parser.
Explicitly setting a context on a block does work.
References
Explicitly setting a context does not work on a reference, but it has revealed that invalid dust is rendered verbatim. I'm going to leave that commented out until I can address that in a later branch.
Paths
Explicit contexts do support deep paths.
Else Blocks
Else blocks also use an explicit context.
Complete Failure
If the walk destination does not exist, and the explicit context does not exist, then you end up with absolutely no context.
Regular Path Failure
If the regular path fails but the explicit path succeeds then the context is set to the explicit path.
Falsey Explicit Path
Since dust would not walk to a falsey path, theres no difference between a falsey path and a non-existent path.