-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: Accessing Masked Data #11
Comments
Hi pvande. I miss something: what is the difference between handlebar's |
Maybe that handlebar's paths are anchored, and that |
Stack: From Handlebars' documentation:
As I interpret this (read: probably wrong), this would basically translate into In Mustache, a lookup for
|
Totally clear, agreed, and let's take it for granted. And I think the "skip" concept is closest to this natural mustache behavior: +1 BTW: don't you think there is a need for a different but related discussion about the need for anchored lookups? I mean, If I don't want to add confusion, but both topics (masked data and anchored lookups) are close enough so that we shouldn't consider one without consider the other in the same time. |
Ha, anchored lookups are discussed at #10 :-) |
As there's no simple obvious solution, I really think the fix is "Sorry :(" Each proposal adds an entire layer of complexity to Mustache itself that isn't needed, it's just nice. I don't think the complexity is worth the niceness. For example you could always rename Naming things is always an issue, in every programming environment: http://laughingmeme.org/2005/12/23/there-are-only-two-hard-things-in-computer-science-cache-invalidation-and-naming-things/ |
defunkt: you forgot the case of recursive partials. |
@defunkt I agree that in most (all?) cases, these proposals are not strict requirements of the language. They are, however, reasonably common cases which trap a number of users. At this point, I would not support any of the mentioned approaches except "skips", because they either a) fail the Mustache-like test or b) add unreasonable complexity. With this comes an implicit claim that "skips" can be supported with minimal complexity: in support of this, I've built a functional prototype for the asserted behavior on top of Milk (diff). As a proposal, its only purpose is to demonstrate one mechanism that would permit non-local access. I'd like to continue the conversation about how else we could provide non-local access, and whether such a feature is a good idea. |
@groue All I care about are real world examples. |
@pvande I don't agree that these are "reasonably common cases". Either way, if anything, this kind of complication should be exposed to Views at the API layer. Not in the template syntax. We should strive to add as little as possible to the template. That's the whole point. |
@defunkt I may have been mistaken about how common an issue this is. I seem to recall hearing questions raised, and I know this is something that has niggled at me while working on the parser side of things, but I may be guilty of sitting too close to the code. Let's table this until we have a concrete need. |
I think this (and all spec discussions) would be improved about 100 fold with some real world examples. |
I have a real-world example: https://gist.github.com/1073313 The problem area is the nested data needs to get access to the _id field of the parent for the onClick javascript code. My only solution here is to write the id field into the dom and walk up the dom if the checkbox is clicked, but that's not an elegant solution. |
@aughey If in your example you replace the The issue being discussed here is that if the hashed named by |
@pvande: imagine the input element had an id, too. This would still be a reasonable real-world-looking example, with two needs for two differents ids at the same level. |
GRMustache 6 has introduced "protected contexts". Protected contexts address different yet related problem. They prevent untrusted templates and untrusted data to shadow important keys. Check https://github.com/groue/GRMustache/blob/master/Guides/protected_contexts.md for a rationale. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
This discussion continues in #154. |
Forked from this comment: #10 (comment)
Data Sample:
@janl I, like you, am still on the fence about the
../
notation.Generally, there are a few ways to conceive of a solution:
{{ @.name }}
would always resolve to'Hello World'
, regardless of stack depth). The downsides to this approach are again exposing the underlying implementation, and eschewing the power of the context stack entirely.{{ name' }}
: not the topmost occurrence of name, but the second;{{ name'' }}
: the third occurrence of name)Of these options, I'm most inclined to support the idea of "skips" at this point.
The text was updated successfully, but these errors were encountered: