New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: More intuitive syntax for simple if comparisons #10

Closed
dswitzer opened this Issue Oct 21, 2011 · 11 comments

Comments

Projects
None yet
3 participants
@dswitzer

dswitzer commented Oct 21, 2011

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

This comment has been minimized.

dswitzer commented Oct 21, 2011

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

@dswitzer

This comment has been minimized.

dswitzer commented Oct 21, 2011

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

This comment has been minimized.

Owner

BorisMoore commented Oct 22, 2011

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

This comment has been minimized.

madaz commented Oct 24, 2011

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

This comment has been minimized.

Owner

BorisMoore commented Oct 24, 2011

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

This comment has been minimized.

Owner

BorisMoore commented Nov 3, 2011

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...

@BorisMoore BorisMoore closed this Nov 3, 2011

@dswitzer

This comment has been minimized.

dswitzer commented Nov 4, 2011

@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

This comment has been minimized.

Owner

BorisMoore commented Nov 4, 2011

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

This comment has been minimized.

dswitzer commented Nov 4, 2011

@BorisMoore:

Thanks for the update!

@madaz

This comment has been minimized.

madaz commented Nov 7, 2011

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

This comment has been minimized.

Owner

BorisMoore commented Nov 7, 2011

{{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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment