Conditionals

[Dave Merrill]

Is there some way to render a section of a template, or not, depending on data? That kind of basic functionality is in all the placeholder-based templating engines I'd rather not use.

Similarly, but different, is there some way to add a DOM attribute that's not there, or not, depending on data? For instance, say a forms engine wanted to add the readonly attribute if the form spec said to. An element with readonly="false" is still readonly, you need not to render the attribute at all.

Thanks,

Dave Merrill

[Jarno Keskikangas]

On 7 July 2013 20:15, Dave Merrill <enig...@gmail.com> wrote:

Is there some way to render a section of a template, or not, depending on data? That kind of basic functionality is in all the placeholder-based templating engines I'd rather not use.

Hi Dave,

I usually implement the logic in ViewModel:

View:

<div class="books-view">

  <ul class="books">

    <li class="book"></li>

  </ul>

  <p class="empty hidden">Oh no, o books to read!</p>

</div>

ViewModel:

var el           = $('.books-view'),

    books        = el.find('.books')

    emptyMessage = el.find('.empty');

function render(bs) {

  books

        .render(bs)

    .toggleClass('hidden', bs.length == 0);

  emptyMessage.toggleClass('hidden', bs.length);

};

render([{book: "Alice in Wonderland"}, {book: "Peter Pan"}]); // shows books

render([]); // shows empty message

 

Similarly, but different, is there some way to add a DOM attribute that's not there, or not, depending on data? For instance, say a forms engine wanted to add the readonly attribute if the form spec said to. An element with readonly="false" is still readonly, you need not to render the attribute at all.

That's true. Luckily, directives take care of boolean attributes (using DOM properties):

View

<ul class="people">

  <li><input name="name" /></li>

</ul>

ViewModel

var data = [

  {name: "Alice", readonly: true},

  {name: "Peter", readonly: false}

];

$('.people').render(data, {

  name: {

  disabled: function() { return this.readonly; }

  }

});

Here's a fiddle for both cases: http://tinker.io/7f639/6

Br, Jarno 

[Dave Merrill]

Thanks for your reply.

Looks like the boolean attributes case would have just worked if I'd actually tried it, instead of just reading :)

For the hidden case, do I gather then that there's no way for Transparency to actually remove sections of the DOM, or not render them? Clearly you can hide them with css, as you showed.

Thanks again,

Dave Merrill

[Jarno Keskikangas]

On 8 July 2013 13:53, Dave Merrill <enig...@gmail.com> wrote:

Thanks for your reply.

Looks like the boolean attributes case would have just worked if I'd actually tried it, instead of just reading :)

For the hidden case, do I gather then that there's no way for Transparency to actually remove sections of the DOM, or not render them? Clearly you can hide them with css, as you showed.

That's correct, if you mean removing also the parent node (the one which you call .render). Of course, if you render an empty list, all the child elements are removed from the DOM.

I seldom use "The list is empty" notifications or such, so I just render empty list, which hides the template nodes, but leaves the parent visible, e.g., 

<ul class="books">

  <li class="book"></li>

</ul>

when rendered with empty list would result

<ul class="books>

</ul>

Which is usually fine, if there's no borders or other visual styles attached on the parent node.

Updated fiddle: http://tinker.io/7f639/7

[Dave Merrill]

Sorry I wasn't more specific. I'm talking more about omitting sections of individual records, or possibly of the page, in response to data.

Say you have a list of items, each of which contains a table of child data. If there are no children, the child rows inherently won't render, but ideally you wouldn't render the whole table and its header row. Similarly, if a record isn't editable, all the edit controls shouldn't be there. Or if a person isn't an admin, whole sections of a dashboard page might be omitted.

Yes, those sections could be hidden with classes, but in at least some security-related cases, it's better not to reveal anything about what goes there, not even hidden labels for unpopulated content. And if there *is* data there, but it shouldn't be shown for permission, workflow, or other reasons, hiding it with css may not be sufficient, since it's still visible in the html source.

Also, Transparency has to do the work to populate those hidden sections.

Don't get me wrong, I love whole idea and the performance of Transparency. I'm just trying to understand what its limitations are before diving in, and wondering how to deal with them.

Thanks again for your replies,

Dave Merrill