Add support for @data variables#3
Conversation
| * | ||
| * @return mixed Last index | ||
| */ | ||
| public function lastIndex() |
There was a problem hiding this comment.
Oh, forgot to drop a comment here. These are being removed because the only usage has been replaced with the variable retrieval within Template.php. The data variables support retrieving the last index ({{@index}}) or relative pathing ({{@../index}}) so we can use the same function for both situations.
There was a problem hiding this comment.
The same applies for the lastKey function below.
There was a problem hiding this comment.
Gotcha, I wonder if we run into any issues by virtue of changing the public API with this though?
There was a problem hiding this comment.
Yeah, I didn't think about that so it's a good call out. I've updated the code to put the new data variables behind a feature flag. It doesn't quite match how Handlebars JS works but it solves the problem of opting-in to the new behavior.
To enable data variables, the user must pass in enableDataVariables when constructing the Handlebars instance. By default this is set to false.
$engine = new \Handlebars\Handlebars(array(
'enableDataVariables'=> true,
));| * @param bool $enableDataVariables Enables data variables (default: false) | ||
| */ | ||
| public function __construct($context = null) | ||
| public function __construct($context = null, $enableDataVariables = false) |
There was a problem hiding this comment.
Trying to think ahead here, maybe this second parameter should be an array of options like you did over on the main class? That way if stuff crops up in the future we're not just endlessly tacking on parameters and maybe have less API breakage that way.
There was a problem hiding this comment.
Good idea - I've updated the code to reflect the suggestion.
sam-osborne
left a comment
There was a problem hiding this comment.
LGTM overall aside from a few minor comments, thanks @jpearson-sfdc !
|
@sam-osborne I've updated the code as you requested. Whenever you get a chance can you take a look? TIA |
@jpearson-sfdc LGTM with the changes. If only Pardot supported the each tag, this seems like it would be a really cool feature for customers. |
| if (!$context instanceof Context) { | ||
| $context = new Context($context); | ||
| $context = new Context($context, [ | ||
| 'enableDataVariables' => $this->handlebars->isDataVariablesEnabled(), |
There was a problem hiding this comment.
nit: You could use that constant here too.
|
@perfectgait & @sam-osborne are we cool to merge this now? |
|
Sorry to put this out there last minute @jpearson-sfdc , but having some basic documentation on how to use this in the README would be good. Even if its just a lift/shift of your PR description above. |
|
@stanlemon I agree with what @sam-osborne suggested. Other than that I think it looks good to merge. |
|
@perfectgait @sam-osborne @stanlemon - Can you give a proofread for the new documentation added to README.md. |
|
LGTM, thanks @jpearson-sfdc I will go ahead and merge this in. |
This PR adds support for data variables
@first,@last,@indexand@keywithin #each (outlined in the latest documentation). These data variables can be used as variables or within the template directly.Given the following template and data:
The output will be
Given the following template and the data above:
The output will be
Data variables also support relative referencing within multiple #each statements.
Given
The output will be
See the attached tests for more scenarios.