Hi David, Setting aside the "data binding" aspect of the problem for a minute..
jQuery, Dojo and other JS libs seem to be going all-in on the "event delegation" paradigm. The idea is: instead of binding event handlers to each individual instance, you let the events bubble up to the top of the document, and then have a single mechanism that matches the [event, eventsource] tuple to the desired function. In effect it allows elements to inherit the dom handlers appropriate to them. The advantages of this are: 1) Performance (no need to attach copies of the same handler everywhere; more opportunities for JITing optimizations) and 2) Code simplification (since adding new elements does not require also attaching their event handlers) . The core matching part seems up the logic/predicate dispatch alley. Extending this kind of event-handling to data binding (for for example having the matched tuple be [event, eventsource, corresponding-model-data] ) might be a way to get at the problem. On Wed, Jan 18, 2012 at 1:21 PM, David Nolen <dnolen.li...@gmail.com> wrote: > On Tue, Jan 17, 2012 at 10:08 PM, kovas boguta <kovas.bog...@gmail.com> > wrote: >> >> Pretty basic question here. >> >> Suppose I want to have 2 copies of the form in the same application. >> >> How will the event handlers know which form the events are coming >> from, and which form needs to be modified in response to those events? >> >> More generally, what if I have N copies of some widget that all have >> the same structure, but different instance data. For example, a list >> of tweets, where each tweet has "favorite" button. >> >> My current impression is that I'd have to architect the event routing >> myself, making sure some distinguishing ID is carried around >> throughout. >> >> Is this accurate? >> >> What is the recommended way to handle this situation? >> >> Thanks, >> Kovas > > > I think it's an open question on how to best solve this problem. There have > been many, many approaches to binding the UI to the data layer. > ClojureScript One's dispatch approach is very interesting, but it might need > something like efficient predicate dispatch to scale. > > It's worth looking at complex binding solutions like Cocoa Bindings and > simple binding UI / data binding projects like Backbone.js or Ember.js to > see how much progress there is to be made in this space. > > If people have other suggestion of things to look at, speak up. > > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
