there are cases when it is helpful to be able to add to the context stack from a lambda callback. To do that, the 'context' needs to be public.
Make context public so that it can be added to from lambda.
I couldn't disagree more with this pull request :)
I was afraid of that. Is it a 'data should be prepared before markup gets processed' thing or something else?
It's that one. It seems like with Mustache it's always that one :P
What specific use case do you have in mind here? Are you looking for something like "enumerate with indexes"?
Hah yeah, I was afraid of that.
If there was a way to dynamically pass a selector to a mustache template that it could use, that would work too probably, for my case anyway.
I know I could just have an extra lambda that did just that (double rendered contents) but was trying to avoid that. maybe its the best solution. It's hard (for me anyways) to see where the line should be..
Or there might even be another way. Can you give me a code sample so I can see what you're trying to do with this?
Essentially, I have structured data with types and lists etc. I am after a good way to pass the same template different data with an extra field pointing to where the data it is interested in is.
There have been a few cases that I found myself wishing I could touch the context but I was able to work around them in ok ways. This one is the one that has me resorting to ReflectionClass etc. but I think I have a way around this by just writing a little more in the lambda fcn.
I am now wrapping the code that would want the extra context in mustache code to access it in the lambda. This works, but is it necessarily better?
You've prolly heard it before, but "prepare your view" might apply here too. I typically use one ViewModel (or Presenter) per template file, and use that to handle the logic needed to bridge the data to the template. I don't know what your ViewModel would look like, but it's usually pretty easy to handle cases like this at that level rather than in lambdas or in the template itself. Then you'd have clean testable code bundled up in the ViewModels, and your invocation wouldn't be much different than it currently is:
$m->render('sometemplate', new SomeTemplateViewModel($data));