lazd
commented
9 years ago Problems with this proposal
I haven't worked enough with dust.js and velocity to have seen this in practice, so forgive my ignorance please! I see a couple problems:
How to access parent data if both parent and child have a property by the same name?
At a glance, it looks like this would have problems if there was a property on the current object (data) that collides with the an object further up the object hierarchy (parent or parent.parent etc). Let's say you had the following structure representing a one-level deep menu:
{
name: 'Furniture',
url: '/furniture'
children: [
{
name: 'Couches',
url: '/furniture/couches'
},
{
name: 'Tables',
url: '/furniture/tables'
}
]
}And a template like:
<!-- Links to the parent's URL -->
<a href="{{data.url}}">{{data.name}}</a>
<if data.children>
<nav>
<foreach data.children>
<!-- Links to the childs's URL -->
<!-- Here, we need to show both the parent and the child's name -->
<!-- If we've combined objects, how do we get to the parent's name? -->
<a href="{{data.url}}">{{????.name}} -> {{data.name}}</a>
</foreach>
</nav>
</if>As you can see, it is no longer obvious how to access the parent's name property in the above example.
Impossible to check if a property is undefined on the current object
Furthermore, it would be impossible to check the direct existence of a property on a the current object without potential interference from parent objects.
Let's say we have a data object like:
{
name: 'Furniture',
url: '/furniture'
children: [
{
name: 'Couches' // No url property
},
{
name: 'Tables',
url: '/furniture/tables'
}
]
}And a template like:
<!-- Links to the parent's URL -->
<a href="{{data.url}}">{{data.name}}</a>
<foreach data.children>
<!-- If we combine the parent and child data, how is it possible to know that the child does not specify a URL? -->
<if data.url>
<!-- Links to the childs's URL, if present -->
<a href="{{data.url}}">{{data.name}}</a>
<else>
{{parent.name}} -> {{data.name}}
</if>
</foreach>Because you can't know for certain where the data.url property is coming from, this will lead to unexpected results.
DOMly's solution to the i18n part of the problem
You've got a couple tools at your disposal.
Use a method of this
You could have a helper function that you invoke when you want to render a template:
function renderTemplate(template, data) {
var context = {
i18n: function(string) { return translated[string]; }
};
// Call the template with this === context
template.call(context, data);
// Return context in case you've used handles in the template
return context;
}Then, inside of your template, this becomes the context object, so you can use this.i18n:
<div><h1 class="{{data.class}}">{{this.i18n("major_heading")}}</h1></div>
<foreach data.groups>
<h2>{{data.name}}</h2>
<ul>
<foreach data.items>
<li>{{this.i18n(data.type)}}: <span class="{{parent.parent.class}} description">{{data.text}}</span>
</foreach>
</ul>
</foreach>Use a global
You can also just refer to a global i18n function:
<!-- This template assumes that MyApp.i18n is accessible in the global space -->
<div><h1 class="{{data.class}}">{{MyApp.i18n("major_heading")}}</h1></div>
<foreach data.groups>
<h2>{{data.name}}</h2>
<ul>
<foreach data.items>
<li>{{MyApp.i18n(data.type)}}: <span class="{{parent.parent.class}} description">{{data.text}}</span>
</foreach>
</ul>
</foreach>Setup variables with <js>
This is as flexible as it gets. You could also use <js> blocks to setup variables you use later in your templates:
<js>
var className = data.class;
var i18n = data.i18n;
</js>
<div><h1 class="{{className}}">{{i18n("major_heading")}}</h1></div>
<foreach data.groups>
<h2>{{data.name}}</h2>
<ul>
<foreach data.items>
<li>{{i18n(data.type)}}: <span class="{{className}} description">{{data.text}}</span>
</foreach>
</ul>
</foreach>The above options allow you to acomplish what you're trying to do and are 100% predictable. Thoughts?
georgkoester
I can create a patch - but would like to know if this has any chance. I am working in a project that is undergoing a change towards DOMly and would really like to have this in the default distribution. Maybe only as a per-template option or as new data variable 'merged' maybe (total would be: 'data', 'this', 'parent', 'merged').
Moustache works different I know, but seriously, I never understood this:
Why can't this just be:
In the moustache case if an extension requires another iteration to be added I also needn't add all those extra parent references:
I would love to look at this from a design perspective, maybe I am missing something that supports the moustache case.