chat about events

gistfile1.txt

[09:37:44] <krusty_ar> so, where do you mostly hook up your events? right now in my project they end up in the views initialize methods, but I'm thinking of puting it outside any backbone class (I'm not using routes yet), is there any other pattern?
[09:38:17] <-- Cromulent ([email protected]) has quit (Remote host closed the connection)
[09:38:32] <krusty_ar> it seems even if events do a nice decoupling, putting the .on call in one of the classes seems like introducing a dependency
[09:39:45] <-- shesek ([email protected]) has quit (Ping timeout: 248 seconds)
[09:40:40] <efdee> why would you not put them in your views initialize methods?
[09:40:47] <efdee> (assuming that your handlers are methods of your view)
[09:41:13] --> shesek ([email protected]) has joined #documentcloud
[09:41:22] <efdee> yes, your view depends on your model (or event bus). but there's nothing wrong with that.
[09:41:30] <krusty_ar> efdee: mainly because it means you need a reference to the model or collection in your view
[09:41:54] <krusty_ar> that's generally a smell in oop, means that both classes depend on each other
[09:41:58] <krusty_ar> not something bad per se
[09:42:15] <krusty_ar> but a thing to avoid in some cases
[09:42:49] <krusty_ar> efdee: I started thinking about this because I'm trying to reuse some view code
[09:43:03] <efdee> 1) yes, your view depends on your model. this is quite natural.
[09:43:05] <krusty_ar> in a different page
[09:43:15] <-- cliffordmeece ([email protected]) has quit (Quit: cliffordmeece)
[09:43:15] <efdee> 2) i don't see how both classes depend on eachother because you have your view depend on the model
[09:43:33] <krusty_ar> efdee: I meant just the view depending on the model, you are correct
[09:43:44] <efdee> maybe in your specific case you have a point but that is hard to say without seeing your specific case :)
[09:43:56] <krusty_ar> but the event idea in general is to avoid doing that kind of things in general
[09:44:28] <krusty_ar> efdee: actually the app is working fine right now, I'm just thinking of how to make the code more robust
[09:44:29] <efdee> no, the event idea is just a classic observer/observable pattern where you have a one-directional dependency (view on model)
[09:44:43] <efdee> if you didn't have events, your model would need to be aware of the view (so bidirectional)
[09:44:53] <krusty_ar> efdee: agreed
[09:44:54] <-- aboudreault (~alanb@osgeo/member/aboudreault) has quit (Ping timeout: 276 seconds)
[09:45:28] <efdee> if you don't want to depend on a model you can also use an event manager that is decoupled from both in true pub/sub fashion
[09:45:56] <efdee> where your view doesn't know the events come from a given model. but imho, your view will almost always need a dependency on your model to get its data.
[09:45:59] <krusty_ar> yes, that was my first idea, just hook up all events in a controller like class
[09:46:04] <krusty_ar> depending on the current context
[09:46:05] <efdee> practically speaking, that is.
[09:46:31] <efdee> i usually have a mix of both - a view depends on a model but also on a more app-wide event manager where it doesn't care who sends the events
[09:47:09] <krusty_ar> efdee: my concern with the view hooking it's own events is also that you have to be careful about some interactions
[09:47:24] <krusty_ar> for instance let's say you have a list view, that listens to the collection
[09:47:35] <krusty_ar> and that collection listens to changes in a "filter" model
[09:47:45] --> antris ([email protected]) has joined #documentcloud
[09:48:04] <-- wookiehangover ([email protected]) has quit (Ping timeout: 240 seconds)
[09:48:31] <krusty_ar> and the filter itself depends on some other more global filter (let's say the user selects the account"
[09:48:54] --> erichynds ([email protected]) has joined #documentcloud
[09:49:21] <krusty_ar> then in some cases, you want the collection to listen to the more general filter directly, so both the filter and the collection render in parallel
[09:49:43] <krusty_ar> but when the filter finishes loading it's data, it will re-render the collection
[09:49:51] --> timkuijsten (~timkuijst@unaffiliated/timkuijsten) has joined #documentcloud
[09:49:52] --> wookiehangover ([email protected]) has joined #documentcloud
[09:50:07] <krusty_ar> so you have to either make separate event classes, or controll all that state in a different place
[09:50:15] <krusty_ar> does that make any sense?
[09:51:00] <efdee> up until the "then in some cases" i was with you :)
[09:51:27] <krusty_ar> efdee: in my case, the "filter" view, has a delay, fetching data
[09:51:55] <krusty_ar> but in the first time the user changes the more global filter, the collection could fetch without waiting for the filter
[09:51:58] <krusty_ar> in parallel
[09:52:25] <krusty_ar> but if the collection blindly listens to the filter, then you will have a second fetch when the filter finishes loading
[09:53:09] --> drale2k ([email protected]) has joined #documentcloud
[09:53:20] <efdee> you mean that the filter will be loading, but in the end it will turn out that there is not yet a filter set, so the collection just re-renders its original content?
[09:53:56] <krusty_ar> efdee: it should do that, so it can listen directly to the general filter, but how do you avoid it re-fetching when the filter is ready?
[09:54:11] <krusty_ar> seems like a bit of logic that doesn't belong in any of the mentioned classes
[09:54:52] <krusty_ar> so I'm thinking on taking most .on calls out of the views
[09:55:01] <krusty_ar> and use some kind of page controller
[09:55:03] <efdee> your collection sohuld be able to figure out that the filter didn't actually change, and wouldn't re-fetch
[09:55:28] <krusty_ar> efdee: exactly, buy then the collection knows too much about the filter
[09:55:45] <krusty_ar> I know I'm being extreme, just looking for patterns
[09:56:15] <efdee> i'm not 100% sure i agree that the collection can know too much about the filter. it should know the state since it is required for fetching - so it can also decide whether or not said state changes
[09:56:20] <efdee> but, you could turn it around
[09:56:33] <efdee> the filter loads itself, sees that the filter didn't actually change and doesn't raise a 'changed' event
[09:57:11] <efdee> that being said, it's not super easy to comment without seeing concrete code to ensure we're talking about the same things :)
[09:57:18] <krusty_ar> efdee: exactly, but let's say you want to reuse that collection with it's view on some other page with no filter or a completely different one, or that in this second page, you do need to wait for the filter to be ready
[09:57:39] <krusty_ar> efdee: of course, but your ideas are what I'm looking for
[09:58:45] <efdee> you could add an option parameter to the collection's initialize method that says whether or not a filter should be ready before rendering
[09:59:00] <efdee> there's a million different roads and half of them lead to Rome
[09:59:25] <efdee> personally, for me right now, it seems that introducing another class just to do the event binding would add complexity that is unnecessary
[09:59:37] <efdee> because who will be responsible of calling this class, etc etc etc
[09:59:41] <krusty_ar> efdee: sure, but you should agree that a class that behaves different on an option that has nothing to do with it's state is rather nasty
[10:00:03] <efdee> nothing to do with its state, but everything to do with its behavior, so it is debatable i guess
[10:00:10] <krusty_ar> maybe
[10:00:29] <krusty_ar> anyway, thanks for your views
[10:00:57] <efdee> if you end up with a piece of code and want to talk about it, don't hold back. this is always interesting stuff :)