Default Values

[hawkett]

It would be great to suport default values for data which is not supplied - e.g.

<div class='${cssClasses | defaultClass1 defaultClass2}'>
    ${content}
</div> 

So in the example, if the 'cssClasses' data item is not supplied, then the value after the pipe symbol (i.e. 'defaultClass1 defaultClass2') is used. No doubt this behaviour can be replicated with {{if}} & {{else}}, but the above is much more readable and maintainable.

[jzaefferer]

You should initialize your data with any necessary defaults, instead of putting that into the template.

[BorisMoore]

Sometimes you don't want to modify the data. For example other 'clients' may be accessing the data. It may be being round-tripped to the server. Keeping this open as a feature request to be considered. (It's is something others have asked for too, and which I have been considering.)

[jzaefferer]

That would invite a ton of otherwise unnecessary features. If you can't modify the original data, you can always make a deep copy with $.extend(true, {}, originalData)

[BorisMoore]

Agree you can do that. We have to find the right balance... Default values may be a strong enough scenario not to want to force cloning of data every time you need a view to fall back to a default string in the case of jagged data, for example. Not saying we have to do it though. Just tracking it for now... :-)

[hawkett]

The use case I have is a template that is very commonly used, and the default behaviour produces a html block that contains a lot of default css classes (~20). User contributed javascript utilises the templates in a widget kind of pattern. I need to make it optional for the user to override the css styles on the widget, but as a percentage of actual uses, this is not common. Being forced to do it in the data means my users need to supply the ~20 default css classes in the template data, when in general they really just want to supply the data object received from the server. The additional js code overhead is significant, especially when I don't want to burden them with even being aware of the css classes until they discover a need to override them.

Sure I could wrap/proxy my various template calls in additional js methods that modify the data, but again, it is a lot messier than needed. It also means I introduce a non-standard API for template use - it is much easier to say to someone 'learn jqeuery templates' than 'learn my custom API that I needed to write to handle defaults'. This is a fairly specific use case (default values) and I can see a lot of situations beyond mine where this feature would significantly reduce the complexity of the client code. Cheers,

Colin

[pingvinen]

I too see a need for default values.

1. I want my view/template to decide what it wants to output as default values, not my logic behind the view.
2. Most templating engines (not just js) supports default values. I know that "the others are doing it" is not much of an argument, but sometimes other people have good ideas :)

[BorisMoore]

I am looking at including support for default values in the ongoing work at JsRender and JsViews. (See #96 for context re: roadmap).

[rdworth]

Thanks for taking the time to submit this issue. Just wanted to let you know this plugin is no longer being actively developed or maintained by the jQuery team. See README for more info.