An Intro to Backbone.js: Part 3 - Binding a Collection to a View(liquidmedia.ca)
liquidmedia.ca
An Intro to Backbone.js: Part 3 - Binding a Collection to a View
http://liquidmedia.ca/blog/2011/02/backbone-js-part-3/
1 comments
Nope -- you're not misunderstanding anything ... you probably wouldn't be writing plumbing like this if you were working on a real app, instead of a contrived example.
You're absolutely right that it's vastly overcomplicated for the task that needs to be accomplished here.
You're absolutely right that it's vastly overcomplicated for the task that needs to be accomplished here.
Do you have any better examples? I'd like to learn more about where this would fit in a real app.
Sure ... some of these have source code available, and some do not.
http://documentcloud.github.com/backbone/#examples
In particular the TileMill example (launched yesterday) is a really sophisticated map editing application, with annotated source code available, here:
http://tilemill.com/docs/models.html
(Use "Jump To", at the top right, to get around)
If you'd like to get your feet wet, and play around with models a little, try visiting http://www.documentcloud.org/public
Pop open a JS console, and try...
http://documentcloud.github.com/backbone/#examples
In particular the TileMill example (launched yesterday) is a really sophisticated map editing application, with annotated source code available, here:
http://tilemill.com/docs/models.html
(Use "Jump To", at the top right, to get around)
If you'd like to get your feet wet, and play around with models a little, try visiting http://www.documentcloud.org/public
Pop open a JS console, and try...
Documents.length
Documents.first().set({title: "Changing the Title Syncs the View"})
Documents.first().set({description: "Lorem Ipsum Dolor Sit Amet"})
Documents.first().notes.fetch()
Documents.first().notes.first().set({content: "Writing a Note."})
The idea of bindings is the same as you're describing, however I don't understand what you mean by donuts being objects mapping to an HTML representation.
In MVC style, a donut model shouldn't know anything about its HTML representation, and there's a 1-* relationship between models and views on those models.
For example, you might have one view of a donut that shows its picture, and another view that shows its ingredients. When displaying a collection, you do want the collection to manage whether to display these things using an HTML list or table or lightbox picture browser or whatever.
But each donut should be a model that knows what it is to be a donut but not how donuts are displayed, each donut view to know how to display a donut, and the collection view knows how to organize what each individual donut view renders.
The other reason you need a view for each donut is that you might want interactivity. For example, if you want a zoom control for a donut picture, that logic would go in the donut view. The donut collection view knows about scrolling, paging, whatever but not zooming. The donut view knows about zooming. And donuts know about sugar and flour and chocolate and sprinkles.
In MVC style, a donut model shouldn't know anything about its HTML representation, and there's a 1-* relationship between models and views on those models.
For example, you might have one view of a donut that shows its picture, and another view that shows its ingredients. When displaying a collection, you do want the collection to manage whether to display these things using an HTML list or table or lightbox picture browser or whatever.
But each donut should be a model that knows what it is to be a donut but not how donuts are displayed, each donut view to know how to display a donut, and the collection view knows how to organize what each individual donut view renders.
The other reason you need a view for each donut is that you might want interactivity. For example, if you want a zoom control for a donut picture, that logic would go in the donut view. The donut collection view knows about scrolling, paging, whatever but not zooming. The donut view knows about zooming. And donuts know about sugar and flour and chocolate and sprinkles.
I didn't meant to say that Donut was itself a mapping from data to representation, just that there is some kind of mapping somewhere. I absolutely agree that Donut should not be concerned with its representation(s).
In Flex, this is managed by a 2-part view consisting of the collection view (List) and the item view (ItemRenderer). When creating the List you pass it its data provider (oft. ArrayCollection) and its ItemRenderer.
Perhaps this example could benefit from a similar separation.
In Flex, this is managed by a 2-part view consisting of the collection view (List) and the item view (ItemRenderer). When creating the List you pass it its data provider (oft. ArrayCollection) and its ItemRenderer.
Perhaps this example could benefit from a similar separation.
[deleted]
I have used binding mechanisms in the Flex framework, which act in a similar way. The model object dispatches events which the view listens to and updates its own representation. In Flex the model object is often an "ArrayCollection," in this example, "Donuts." In Flex the view would often be some kind of "List" object, in this example, "DonutCollectionView."
The Donut aspect of this example is the contrived bit. It's just a generic list. Donut could just be any Object that maps to some kind of HTML representation. DonutCollectionView could just be a CollectionView, that passes along that representation to a HTML list.
The plumbing in this example is something I don't really want to write if I am using a framework. If I had to write it, I wouldn't write it like this. Am I misunderstanding something?