Syntax...

[sitefinitysteve]

Here's the thing...templates are cool, I love templating...however I'm not a fan of the Kendo syntax.

I think jQuery templates got it right with ${name}

<# name #> becomes confusing when you start having templates with html tags...

'<a class="videolink" href="http://url.com?id=<#= nodeid #>">link to video </a>'

vs

'<a class="videolink" href="http://url.com?id=${nodeid}">link to video </a>'

Of anything Kendo...the template syntax is by far I think the worst design decision (only bad one?)

[Atanas Korchev]

Hello Steve,

 Perhaps you have missed this example. It shows that ${} is also supported by the Kendo UI templates and it does a slightly different thing than <#= #> - it performs html encoding of the value whereas <#= #> does not. Both expressions serve a different purpose and it is up to you to decide which one to use.

Regards,
Atanas Korchev
the Telerik team

[sitefinitysteve]

Yeah I saw that, but look the principle still stands that you're using "<" ">" symbols for expressions which 99.9% of the time wrap around html which also uses those for tags.

This is your expression in that example

<script id="javascriptTemplate" type="text/x-kendo-template">

    <ul>

    <# for (var i = 0; i < data.length; i++) { #>

        <li><#= data[i] #></li>

    <# } #>

    <ul>

<script>

This is that in jQuery templates

<ul>

     {{each(i, val) $data}}

         <li>${val}</li>

     {{/each}}

</ul>

So it's a different way to do the same thing, but way more readable since we don't have extra < > <  > < > > > < >

(incidentally typing this I noticed you don't close the <ul> tag on that page sample

Steve

[sitefinitysteve]

JustCode did the same type of thing early on with their templating engine where they decided to use $ as one if the main characters...so obviously that causes conflicts or with writing JC jQuery (or at the very least horrible to read templates).

[Atanas Korchev]

Hello Steve,

 Thank you for the feedback. The template syntax is not yet set in stone so this kind of feedback is very helpful to us. How about this syntax:

<ul>

    {{ for (var i = 0; i < data.length; i++) { }}

        <li>{{= data[i] }}</li>

    {{ } }}

</ul>

Does it look better? We can easily switch to that.

Bottom line is this:

{{ and }} mark start and end of executable block (similar to <% and %> in many server-side platforms)

{{= }} emits raw value in the output (similar to jQuery templates)
${  }  emits html encoded value in the output (similar to jQuery templates)


Regards,

Atanas Korchev
the Telerik team

[sitefinitysteve]

I was actually typing that out, but then you get the problem with {{  } }} { }} :)
 
Damnned if you do, Damned if you don't eh :)

IMO that's more readable to me as I wouldn't really have a ton of if statements, but you aren't building it for ME only :)

What if you guys created a few samples and put out a survey over twitter?

[Atanas Korchev]

Hi Steve,

 jQuery templates (and lots of other templating libraries) solve the {{ } }} problem by having ugly things like {{ /each }}. To me this leaves the impression that templates are some sort of XML-like markup language which they are not. Templates translate to JavaScript in the end and perhaps we should not make big efforts to hide that behind closing tags (/each, /for) etc.

Maybe we just need another delimiter than "{{" and "<#" which which does not contain "{" or "<" or symbols used by server side platforms ("<%").

Any ideas?

Regards,
Atanas Korchev
the Telerik team

[Todd Anglin]

A few things to remember:

1. Kendo UI is designed with "escape hatches" so you can work with any JavaScript templating library you prefer.
2. Kendo UI is trying to optimize the out-of-the-box components for performance.
3. There will never be one templating syntax to "rule them all" that everyone likes.

I agree that now is the time to work on the Kendo UI template syntax, but ultimately, the reason we have Mustache, HandlebarJS, jQuery Templates, and others is because templating syntax is often a matter of preference.

Whatever we do with Kendo UI, I think we should focus on keeping it fast.That's one of the main benefits of Kendo UI Templates today vs. implementations like jQuery Templates- it's much faster. Some of the syntactical sugar requires extra JS processing to unwrap- slowing the templating process- so I think we should try to avoid some of those implementations. If we're just a Mustache/jQuery Templates/etc clone without the perf benefits, we defeat the purpose.

SYNTAX
I tend to agree that the <# #> syntax feels heavy inside of HTML. Implementations I like:

• {{ variable }} for rendering without encoding values
• {{{ variable }}} for encoding values (a la Handlebars)
• @variable or @{variable} (a la Razor)
• @@variable or @{{variable}} or @html(variable) (maybe for HTML encoding?)

Really, though, this is mostly just simple RegEx pattern changing (Razor would require a bit more). The expression syntax is a bit more challenging. Options:

• {{ if expression }} ... {{/if}}
• <# if expression { #> ... <# } #>
• {{ kendo.if(expression, function(){ ... }).else(function(){ ... }) }}
• @if (expression) { ... }

In context:

<ul>
    {{ kendo.each(items, function(item){ <li> {{item}} </li> }) }}
</ul>

<ul>
    <# for (var item in items) { #>
    <li> <# item #>
    <# } #>
</ul>

<ul>
    {{each(item, items)}}
    <li>{{item}}</li>
    {{/each}}
</ul>

<ul>
    @foreach(var item in items){
        <li>@item</li>
    }
</ul>

Frankly, I think a JavaScript implementation of Razor would be awesome, but I doubt it can be done with speed since it would require much more context parsing. If that's true, I guess I'm partial towards the Mustache syntax, though the flood of "mustaches" is a bit annoying. I guess it's like I said, there is no perfect solution...

[Atanas Korchev]

Hello,

 No matter what delimiter we pick the parsing performance and generated code will remain the same as long as we keep it simple - no {{each, no {{ /if }} etc.

 Razor-like syntax looks great but the Razor view engine will try to evaluate it as well (server-side) which is why we must not use a delimiter used in server template engines in the wild (this is the reason <%= %> is out of the question as well).

Here is my comment on every option:

<ul>
    {{ kendo.each(items, function(item){ <li> {{item}} </li> }) }}
</ul>

Not sure we can parse that as there is nesting of {{ . We need a full blown parser with grammar to be able to parse this properly which is perhaps out of scope.

<ul>
    <# for (var item in items) { #>
    <li> <# item #>
    <# } #>
</ul>

The current somewhat ugly option. Picking a better looking delimiter here would help. Mustaches {{ have the drawback of being a JavaScript special symbol and too many mustaches hurt the eyes too. If we want to keep the templates JavaScript like we better find an alternative delimiter.

<ul>
    {{each(item, items)}}
    <li>{{item}}</li>
    {{  /each }}
</ul>

jQuery Templates like solution (the latter uses {{=item}} instead of {{item}} ). The thing I don't like is the closing tags. I find them awkward but heck every existing engine seems to use them. Not sure if this allows arbitrary JavaScript code though.

<ul>
    @foreach(var item in items){
        <li>@item</li>
    }
</ul>

This won't work in an ASP.NET MVC Razor view page as Razor will pick it up and try to parse it.

The way I see it we have two options:

1. Find a better looking delimiter which satisfies this regexp: [^{%#@]. We need three flavors
   - for embedding arbitrary JavaScript expressions
   - for emitting raw values
   - for emitting html encoded values
2. Pick the mustaches as delimiter and implement the {{each}} {{/each}} pattern to avoid using single { in the template definition. Keep the current support for arbitrary JavaScript (if at all possible).

I hope this makes sense!

Regards,
Atanas Korchev
the Telerik team

[Atanas Korchev]

Hi,

 After a short discussion with the team we have proposal for a new delimiter - a single # (hash, sharp). Here is how a template would look like:

Expressions and raw data - #= data #:

<ul>
    # for (var item in items) { #
          <li> #= item # </li>
    # } #
</ul>

Expressions and encoded data - #: data #:
<ul>
    # for (var item in items) { #
          <li> #: item # </li>
    # } #
</ul>

Escaping # - \#:

    # for (var item in items) { #
          <a href="http://www.example.com/\#foo">#: item #</a>
    # } #


Does this look better than the mustache soup?

Frankly I am not a big fan of cloning the syntax of existing JavaScript template engines. If one is used to another template engine - Kendo will support that as an alternative.

Regards,
Atanas Korchev
the Telerik team

[Todd Anglin]

Assuming the syntax works for all edge cases, I like it! It even caters to a cool name:

#Templates (Sharp Templates) or HashTemp or MicroHash or Templates++++ or Kendo UI Templates... :)

I 100% agree that it's not worth just re-implementing the syntax of an already available library. As you said, developers can easily plug-in their preferred library if they don't like the Kendo UI approach.

The proposed syntax does seem to nicely reduce some of the visual clutter. And I like that you've already anticipated the URL hashtag escape sequence!

I'm a bit surprised we've not seen this tried before, so I'm wondering if there is an edge case we're not considering. I think this is a very nice compromise, though. Well done.

-Todd

[HHalim]

A single simple delimiter is much preferable than the multiple characters.

Never liked the mustaches, +1 for the # or maybe *, %, !, whatever simplest and easiest to type and easy on the eyes.

[Burke]

I'm late coming into this thread and not sure If I can offer any good options, but my here are my thoughts...

1. The <#= syntax is definitely heavy and the use of carrots is a bit tedious.
2. I am not a fan of the {{ syntax as it's going to collide logically with javascript if you embed that in your template (not that you should do that).
3. I agree that a single character solution would be best if possible.
4. I don't like the thought of @ because that seems like Razor's territory.  I'm not really sure how it would look or act though in real life.

I like the # sequence and I have implemented this in the past as #{ }#, but I don't see the need for the {}.  I think the sharp suggestion would work really well.

[Obi]

The # is a good start, but it's used in HTML and has to be escaped in the example.com#foo case. What about ` (backtick) ? Easy to type, no SHIFT-pain, no need to escape it most of the time. The tilde (~) is also an option, heck, I prefer KUIT:: to <#= (Kendo UI Template :))

Also, if possible, can you make it so if the Special Char appears only once, the entire line is code? Like this (if we use hashish sign):

<ul>
    # for (var item in items) {
          <li> #= item # </li>
    # }
</ul>

Lovely! Now with backticks for bonus awesomeness:

    ` for (var item in items) {
          <a href="http://www.example.com/#foo">`: item `</a>
    ` }

Lovely!

All of a sudden I'm thinking how hard it would be to implement Common Lisp's FORMAT in JS...

[Atanas Korchev]

Hi Obi,

 Unfortunately we cannot implement this:

# for (var item in items) {
          <li> #= item # </li>
 # }

Users can easily omit the new lines:

# for (var item in items) {  <li> #= item # </li> # }

and end up with something which cannot be parsed.

Backticks seem too small and can easily be missed. Not to mention that they are often mistaken for apostrophe (' vs `).

Here is how the example would look like with tilde:

<ul>
    ~ for (var item in items) { ~
          <li> ~= item ~ </li>
    ~ } ~
</ul>

Still I prefer #. I also think escaping will always be required no matter what delimiter we pick - there is always a case when you would want to output the delimiter symbol in your template.

Regards,
Atanas Korchev
the Telerik team

[HHalim]

After thinking about this more, it seems that sharp:# is the best choice. Some delimiters are too small and hard to see: `, ^, *, ~.

[Tony]

Excellent technical discussion in the thread.

 +1 for the #

[Chris]

Not real crazy about using the hash (#) here... it is the main symbol used in Adobe's ColdFusion markup language.

[Todd Anglin]

@Chris- That's a fair point. I suppose in any debate/decision like this it's very hard to find a solution the pleases all audiences.

For ColdFusion, unfortunately, it is a solid "4th place" language for the web, hovering in terms of adoption around Perl (used in less than 2% of websites):
http://w3techs.com/technologies/details/pl-coldfusion/all/all

And of that adoption, much is suspected to be "legacy" sites and not the type of sites likely to be adopting Kendo UI. Still, your point is very valid and something to consider. If we adopt the "Hash Templates" format, we'll do some testing to see what can be done to support ColdFusion developers. Very likely, with a small configuration/regex change, you could substitute the default selector for a different character (like ~).

Thanks for the input.

-Todd

[RainerAtSpirit]

First of all I appreciate the speed aspects of Kendo templates. For the concrete syntax I'm completely agnostic, so I second Todd's recommendation. Something along the line of what underscore allows you to customize delimiters would most likely do the trick.
http://documentcloud.github.com/underscore/#template

Rainer

[dandv]

My post is probably way too late to influence any decision, but:

1. What exactly is wrong with the Handlebars syntax? Since this discussion was started, Handlebars was adopted by a very popular full-stack JS framework, Meteor (21,000+ stars on GitHub).

{{#each topScorers}}
    <div>{{name}}</div>
  {{/each}}

2. I keep seeing it's possible to use "escape hatches" for other template languages - but how exactly? (A quick search reveals this demo). Please add how to use Handlebars/etc. to http://blogs.telerik.com/kendoui/posts/11-08-26/kendo_ui_templates_faster_than_a_speeding_resig (see also the last comment there) and http://docs.telerik.com/kendo-ui/framework/templates/performance