Skip to content

Make 'context' public in lambda helper #137

Closed
wants to merge 1 commit into from

2 participants

@arrowplum

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.

@bobthecow
Owner

I couldn't disagree more with this pull request :)

@arrowplum

I was afraid of that. Is it a 'data should be prepared before markup gets processed' thing or something else?

@bobthecow
Owner

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"?

@arrowplum

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.

@arrowplum

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..

@bobthecow
Owner

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?

@arrowplum

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.

@arrowplum

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.

@arrowplum

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?

@bobthecow
Owner

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));
@bobthecow bobthecow closed this Apr 27, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.