Make 'context' public in lambda helper #137

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
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

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Mar 7, 2013

Owner

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

Owner

bobthecow commented Mar 7, 2013

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

@arrowplum

This comment has been minimized.

Show comment
Hide comment
@arrowplum

arrowplum Mar 7, 2013

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

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

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Mar 7, 2013

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

Owner

bobthecow commented Mar 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@arrowplum

arrowplum Mar 7, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@arrowplum

arrowplum Mar 7, 2013

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

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

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Mar 7, 2013

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?

Owner

bobthecow commented Mar 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@arrowplum

arrowplum Mar 7, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@arrowplum

arrowplum Mar 7, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@arrowplum

arrowplum Mar 8, 2013

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?

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

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Mar 8, 2013

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));
Owner

bobthecow commented Mar 8, 2013

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