5 ms·

I've never been able to get behind defining data relationships in the DOM. I do like the idea of not having to re-render the entire view or explicitly update i

I've never been able to get behind defining data relationships in the DOM. I do like the idea of not having to re-render the entire view or explicitly update individual elements on data change events, but i wish there was a better way. Perhaps a view could contain a hash associating data change events with element selectors. Then the view knows which element to update. That way the html clean and ignorant of the underpinnings of the app.

ansman 14y ago
But on the other hand the view has to know about the template. Change a tag name or class name (which I think is far more common than attribute names) would then break the relationship.
- joshontheweb 14y ago
  This is true. However, the view already has to know about the template. The only difference is the how much it knows. It will add some extra responsibility if you change your classes a lot but I think I might prefer that over muddying the html with attributes and filters. Another thing that would be cool about a hash in the view is you could apply filters and presentation logic to the values there in a DRY way. Hope my tone doesn't come across as combative or dismissive. Thanks for taking the time to open source your code. I've just been thinking a lot about this recently.
  - ansman 14y ago
    Hehe, it's not actually my code, I just found this gem and I liked it :)
amccloud 14y ago
I'm had the same exact thought. That's why I created https://github.com/amccloud/backbone-bindings https://github.com/amccloud/backbone-bindings
- joshontheweb 14y ago
  Nice, This is cool, pretty much what I had in mind with some cool additional features. It seems like you could just pass the template to bindModel, fire a change, and have it do the initial render and cut out _.template altogether.
  - amccloud 14y ago
    Template markup is generally more complex than that and certainly more complex than your bindings. The ability for designers to edit and change the markup without having to look at code is a plus for using templates. Not to mention as a backbone convention it is expected so it makes things more portable.

ansman 14y ago

But on the other hand the view has to know about the template. Change a tag name or class name (which I think is far more common than attribute names) would then break the relationship.

joshontheweb 14y ago
This is true. However, the view already has to know about the template. The only difference is the how much it knows. It will add some extra responsibility if you change your classes a lot but I think I might prefer that over muddying the html with attributes and filters. Another thing that would be cool about a hash in the view is you could apply filters and presentation logic to the values there in a DRY way. Hope my tone doesn't come across as combative or dismissive. Thanks for taking the time to open source your code. I've just been thinking a lot about this recently.
- ansman 14y ago
  Hehe, it's not actually my code, I just found this gem and I liked it :)

amccloud 14y ago

I'm had the same exact thought. That's why I created https://github.com/amccloud/backbone-bindings https://github.com/amccloud/backbone-bindings

joshontheweb 14y ago
Nice, This is cool, pretty much what I had in mind with some cool additional features. It seems like you could just pass the template to bindModel, fire a change, and have it do the initial render and cut out _.template altogether.
- amccloud 14y ago
  Template markup is generally more complex than that and certainly more complex than your bindings. The ability for designers to edit and change the markup without having to look at code is a plus for using templates. Not to mention as a backbone convention it is expected so it makes things more portable.