Suggestion: More intuitive syntax for simple if comparisons

[dswitzer]

The syntax for implementing simple comparisons is overly complex and I think there should be simpler method for adding simple comparisons to your template code.

For example, in jquery.tmpl, you could do:

<div class="base{{if varName == 'None'}} none{{/if}}">${varName}</div>

However, this simple comparison is much more difficult in the new engine. First, you've got to set:

$.views.allowCode = true;

And then your template ends up looking something like this:

<div class="base{{* if($view.data.varName == 'None'){ result += ' none';  } }}">{{=varName}}</div>

This is quite a bit more complicated to implement and much more difficult to interpret.

Any chance of being able to implement something like:

<div class="base{{#if equals(varName, 'None')}} none{{/if}}">{{=varName}}</div>

Where we have some functional helpers like equals(), not(), gt(), lt(), gte(), lte()--and with the potential to define more helper functions.

I can understand dropping to code view for more complex operations, but it seems like there should be a way to at least perform some simple comparisons w/out having to drop to the overly complex code syntax.

[dswitzer]

If not clear, this syntax would not require setting the $.views.allowCode to true.

[dswitzer]

I should have done this first, but it actually looks like that functionality is basically there:

<div class="base{{#if varName eq='None')}} none{{/if}}">{{=varName}}</div>

This really needs to be documented (along with the other values (ne, lt, gt, le, ge.) Also, it would be more intuitive if the "=" sign wasn't needed, but that would probably complicate the hash parsing engine too much.

Also, I think "lte" and "gte" would be better names than "ge" and "le". The vernacular "lte" and "gte" seemed to be more common in other languages I've seen.

[BorisMoore]

The lack of documentation is because a) none of the APIs are actually documented yet. Just indirectly via the samples. b) This was only added to the implementation yesterday :) - c) I am not yet sure that this is the right design, so I didn't really want to draw too much attention to it yet...

Still, your questions were spot on (that scenario was driving both your questions and my design...).
It will stay undocumented for the moment until I have had time to settle on whether this design will stay...

[madaz]

Not sure if best place but I am converting from tmpl to render

I am trying to do a number eq without having to write a custom tag as there seems to be a bug as its trying to compare a number to a string

(Using jsRender version as at 24-Oct-2011)

When passing a number to the eq function the internal hash.eq does not contain the number passed in

{{#if $itemNumber eq=1}}First{{/if}}

If you pass a number in quotes, internally hash.eq contains value but as a string, so the condition is never equal.

{{#if $itemNumber eq='1'}}First{{/if}}

[BorisMoore]

I am working on a replacement for this, so for the moment it is better just to use custom tags, and not to use the named parameters like eq an lt. I have removed this feature in the latest commit.

There are some significant changes likely to come soon on in order to make it easier to support these scenarios. Chained tags will also likely be replaced by a different way of calling helper functions...

[BorisMoore]

Fixed in df3e1e2.
You can do {{#if a===b}} {{#if a<b}} etc. You can also use a===b etc as boolean values passed elsewhere,
e.g. {{=foo(a>=b, c===3, name>"a"}}.
Nevertheless, {{=alert()}} will NOT work. No random eval of expressions allowed :).
Let me know/reopen if the fix does not work for you...

[dswitzer]

@BorisMoore:

Would you consider this syntax "stable?" I just want to know whether I need to dictate in my code whether or not this syntax could change in the official release.

[BorisMoore]

I think it will be stable, but the caveat would be if jQuery UI make a strong case for some change. In that case I would need to decide whether to adapt to their request or not... The hope is that JsRender might work both for jQuery UI requirements and scenarios, and for other user scenarios which could be somewhat different...

[dswitzer]

@BorisMoore:

Thanks for the update!

[madaz]

Thanks, Just had to write some unit tests around jsrender to catch all your refactring.

All my tests pass. I can also now also do {{#if arr.length > 0}} which I had to do before with a custom helper.

How do you do multiple conditions without nesting? {{#if}} e.g. {{#if a===b && c !== d}}

[BorisMoore]

{{if a===b c!==d}} will work for a===b||c!==d - and you can chain as many as you want.
But for a===b&&c!==d you will need to pass to a helper function.