support data-bind-attr without verbose mapping #58

wants to merge 2 commits into


None yet

5 participants

autoric commented Apr 10, 2012

Updated the default behavior of plates so that:

*Data is bound to a tag by using data-bind="key"; id or any other attribute will not cause data to be bound
*Any attribute can be set using data-bind-attr="key"
*Attribute creation is on

No custom maps need to be written to achieve this behavior. Writing any mapping will override this behavior with your manual bindings.


<a data-bind-href="url" data-bind="title"></a>


var data = {
        title:'This is a link to google'

Plates.bind(html, data)


<a href="" data-bind-href="url" data-bind="title">This is a link to google</a>
autoric commented Apr 10, 2012

Didn't realize the pull request would open a new issue.... I'm moving my comments from the previous feature request & deleting it to prevent redundancy -

The wiki docs sugest using data-bind="name" or data-bind-href="url" for clean templating, which I totally agree with (

However, right now it looks like to support that, you have to manually write your map for every data item -


It seems like either the default behavior should support the best practice, or there should be a simple way to hand the map a regex and a function such that data-bind-attr="key" will always bind attr="data[key]". If we could agree on the best approach I would be glad to take a shot at implementing.

autoric commented Apr 10, 2012

To expand on this -

I've been trying to think of a way to execute this cleanly. One path I was considering is extending the Map prototype to include something along the lines of .match(regex) and .execute(callback). However that probably just moves down the road of offloading the work onto each user, and sort of defeats the purpose.

Instead, I want to try extending the default functionality of plates (ie where there are no mappings), to achieve the desired functionality. This still leaves users with the option of overriding with explicit maps but makes the standard behavior more robust.

Does this make sense; does anyone else felt like this would make plates more usable & accessible?

tauren commented Apr 11, 2012

I agree with adding data-bind features to plates. I'm already using data-bind instead of id or class, and it is tedious to have to manually create all of the mappings.

Also, I absolutely think that plates should accept functions as well as strings for parameters in the mappings. I discuss this some in this issue:

autoric commented Apr 12, 2012

Thanks for the input, tauren. I actually have been thinking recently that plates might be improved by dropping maps & mappings altogether. In my experience the most useful templating engines are very simple with a small set of rules (thinking of mustache js for instance).

I'll outline my thoughts, would love to hear feedback -


Plates parses html and binds based exclusively by the following two attributes in html tags. These accept certain types of data values and behave differently depending on what that type is (explained below):

  • data-bind="[key]" - accepts data types of string, array, object, boolean, function. Maps the inner html of the current tag to the value in data[key]
  • data-bind-[attr]="[key]" - accepts data types of string, boolean, function. Replaces the value of attr or adds attr to the tag, with the value of data[key]

Data value types

  • String - simple value replacement, exactly as plates works right now
  • Array - iterate over the array, same as plates works now
  • Object - iterate over the object and all subelements operate in the context of the object, same as plates works now
  • Boolean - a boolean true does nothing, a boolean false removes the attribute (data-bind-[attr]), or the html tag and all child elements (data-bind). Essentially gives you conditionals in your templating.
  • Function - A callback function. I have thought about this the least, but possibly gets the arguments of regex matching, and should return any of these other valid types. This should allow you to append values, in the case of wanting to add a class, or simply append text to the end of div.

If this is unclear or there is interest, I could write some code mockups clarifying the idea. In this case, I think maps can safely be dropped, and plates would provide an easy to understand & very powerful set of rules, all entirely html5 compliant and avoiding the DSL it set out to dodge.

0x00A commented Jul 20, 2012

looking at this now.

msull92 commented Aug 6, 2012

Already using these commits in my code! Thank you!!

msull92 commented Aug 7, 2012

With this, is it possible to access nested JSON data?

0x00A commented Aug 24, 2012

There were so many whitespace/indent changes in this commit it was kind of hard to read, also, its been a while so its out of sync with HEAD, can you update this so i can merge it in?


Closing due to age. This project is formally deprecated. Will be adding a notice soon.

@indexzero indexzero closed this Jan 26, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment