Direct addressing of specific array elements

[davemerrill]

This works fine, iterating over the elements in an array:

data = {arr=[10,20,30]}; template = "{{##arr}}{{.}}{{/arr}}"; writeOutput(mustache.render(template, data));

How can you show just element 2, say? Not with any of these seemingly intuitive constructs:

template = "{{arr.2}}"; template = "{{arr[2]}}";

My actual use case is more like this:

data = {arr=[{a=10, b=11}, {a=20, b=21}]}; template = "{{arr.2.b}}"; // or whatever would work to output '21'

The similar case of addressing a specific struct item does work, for instance:

data = {s={a=10, b=20, c=30}}; template = "({{s.b}})"; // -> '20'

Is the array element index version of this possible today with some syntax I missed? If not, is it a reasonable enhancement?

Thanks.

[dswitzer]

This (to my knowledge), isn't supported by the Mustache spec. Keep in mind that Mustache is supposed to be "logic-less" and in a template you probably should not be hardcoding a reference to a specific index.

I would suggest the better way to solve this problem is just to have your code pass in the 2nd element of your array, instead of passing in the full array. Then your template is just dealing with the specific data structure, instead of having a dependency on an array formatted a specific way.

[davemerrill]

Thanks Dan, I thought that might be true, and I confess to not having read that spec.

And in principle I agree that locating data by its array index is fundamentally bogus in many situations, but a) not all, like an array of image sizes where you want the smallest one, and b) it's the current reality in my case.

However, colors[1] doesn't strike me as a ton more logic-full than person.identity.lastName, which is supported. The idea as I understand it is that each dot pushes something -- the next drilled-down-to nested struct for instance -- onto the context stack. The array version of this I think is supported in php, don't know about js or other implementations.

[pmcelhaney]

What does colors[1] mean exactly? Could you change the model so it's more explicit, e.g. colors.secondary?

On Mar 8, 2016, at 12:52 PM, Dave Merrill notifications@github.com wrote:

Thanks Dan, I thought that might be true, and I confess to not having read that spec.

And in principle I agree that locating data by its array index is fundamentally bogus in many situations, but a) not all, like an array of image sizes where you want the smallest one, and b) it's the current reality in my case.

However, colors[1] doesn't strike me as a ton more logic-full than person.identity.lastName, which is supported. The idea as I understand it is that each dot pushes something -- the next drilled-down-to nested struct for instance -- onto the context stack. The array version of this I think is supported in php, don't know about js or other implementations.

— Reply to this email directly or view it on GitHub.

[dswitzer]

@davemerrill,

I still think the view template should be pretty dump. Knowing the "smallest" is probably too much business logic. Instead, just create a view template that renders the output you're looking for and then have your code pass in the element at the correct array position. Then you can use that template for the first item, the last item or any item.

Support for array position seems to be split, which becomes problematic when you try to use the same template in multiple languages.

If the spec does support it, then it makes sense to add it. If the spec indicates it shouldn't then I don't think it should be added.

That said, you can always extend the component to create a version that does support positional arrays.

[davemerrill]

@pmcelhaney Not to be flip, but it means the first element in the colors array (:-). The idea (before my time) apparently was that the array of available sizes is exposed to the template designer, so they can use whichever one(s) they want. Yes it might make sense to give them names, but changing the data model is out of scope for what I'm doing, and would break code outside our organization.

The overall context is that I'm evaluating MustacheCFC as a power-end-user templating engine for designer types who don't know CFML, making sure I understand the limits so I can talk about them.

(OT: Didn't want to open another issue just to ask this, but if any of you are on CFML Slack, I asked about setting up the MXUnit tests for this project, by all means jump in.)

[dswitzer]

@davemerrill: You don't have to change the original data, but that doesn't mean you can't transform the data before passing it to the template view.

It would seem like expecting a designer to understanding the positional items might be asking a lot, but if you transformed the data so that array was transformed into meaningful items (first, last, mostpopular, etc), then maybe that's helpful.

[davemerrill]

@dswitzer Yes, you're right, there aren't any external consumers of this (potential) mustache data yet, it'd be a new feature. One of the things I'm looking at for this integration is how much of what sorts of data transformations should happen between existing internal data and mustache-land.

Thanks again.

[pmcelhaney]

The idea is to have data prepared for presentation as much as possible, but still available as an API that can be easily tested and isn't subject to change with every tiny UI refinement.

Everything that Mustache is incapable of doing intentional and for your benefit. :)

On Mar 8, 2016, at 2:52 PM, Dave Merrill notifications@github.com wrote:

@dswitzer Yes, you're right, there aren't any external consumers of this (potential) mustache data yet, it'd be a new feature. One of the things I'm looking at for this integration is how much of what sorts of data transformations should happen between existing internal data and mustache-land.

Thanks again.

— Reply to this email directly or view it on GitHub.

[davemerrill]

Understood, my question arose from me making sure I understood the limits of this tech, and that one doesn't seem to apply to all implementations, for instance apparently not PHP.

I do agree that naming these image sizes (one specific bit of data I happened to be looking at) is a better idea, and not just for mustache. Will investigate how that data is currently being used, and possibly propose a change.