Comments on: Don’t Execute A Backbone.js Route Handler From Your Code http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/ Better Than Yesterday Fri, 24 May 2013 06:39:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: simplynutty http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-3174 simplynutty Thu, 04 Apr 2013 04:09:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-3174 Thanks! The lack of "you have to code this way" is what I love about backbone but it's also frustrating. I came up with at least 3 or 4 different ways to solve a problem I've been working on and could talk myself in or out of all of them. :/ Thanks! The lack of “you have to code this way” is what I love about backbone but it’s also frustrating. I came up with at least 3 or 4 different ways to solve a problem I’ve been working on and could talk myself in or out of all of them. :/

]]> By: Derick Bailey http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-3173 Derick Bailey Wed, 03 Apr 2013 12:22:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-3173 if you're just grabbing the hash fragment and passing that to the router, don't bother. just let the browser fire the navigation event when the link is clicked. this article is rather convoluted, and difficult to follow, honestly. i didn't do a good of explaining the nuances and situations. i should re-write this at some point. if you’re just grabbing the hash fragment and passing that to the router, don’t bother. just let the browser fire the navigation event when the link is clicked.

this article is rather convoluted, and difficult to follow, honestly. i didn’t do a good of explaining the nuances and situations. i should re-write this at some point.

]]> By: simplynutty http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-3172 simplynutty Wed, 03 Apr 2013 03:49:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-3172 @derickbailey:disqus What's your take on this? I think I understand the example you used which is model-based but what about navigation links which aren't really tired to a model? I have a few links in the header: #projects, #admin, #reports and I have a method which grabs the data-fragment value and passes it to router.navigate. I'd rather just use plain hrefs. Thoughts? @derickbailey:disqus What’s your take on this? I think I understand the example you used which is model-based but what about navigation links which aren’t really tired to a model? I have a few links in the header: #projects, #admin, #reports and I have a method which grabs the data-fragment value and passes it to router.navigate. I’d rather just use plain hrefs. Thoughts?

]]> By: Derick Bailey http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-3168 Derick Bailey Fri, 29 Mar 2013 17:31:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-3168 i usually do that in my "mediator" objects (aka "workflow" objects): http://lostechies.com/derickbailey/2012/05/10/modeling-explicit-workflow-with-code-in-javascript-and-backbone-apps/ that example shows view events being bound, but the same idea applies - just binding to the event from a different object. i usually do that in my “mediator” objects (aka “workflow” objects): http://lostechies.com/derickbailey/2012/05/10/modeling-explicit-workflow-with-code-in-javascript-and-backbone-apps/

that example shows view events being bound, but the same idea applies – just binding to the event from a different object.

]]> By: Jake Smith http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-3167 Jake Smith Fri, 29 Mar 2013 17:18:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-3167 Where would be a good place in the application to bind the "post:selected" event? Does it make the most sense to bind the event in the view that's being loaded? That doesn't seem right to me though. Where would be a good place in the application to bind the “post:selected” event? Does it make the most sense to bind the event in the view that’s being loaded? That doesn’t seem right to me though.

]]> By: maoshuyu http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-2980 maoshuyu Thu, 17 Jan 2013 15:50:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-2980 test test

]]> By: Edan http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-2813 Edan Wed, 31 Oct 2012 12:50:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-2813 Hi Derick - Thanks for the great article! Could you talk a little bit about directly accessing a route from the `href` tag? I know that your code snippet is a distillation of a more complex application, But I'm wondering if you could have, in this instance, created the route directly in an HTML template? eg. <a href="#posts/"></a> In other words, why do you need to bind this link in the javascript code at all? What are the advantages/disadvantages of this method? Hi Derick –
Thanks for the great article! Could you talk a little bit about directly accessing a route from the `href` tag? I know that your code snippet is a distillation of a more complex application, But I’m wondering if you could have, in this instance, created the route directly in an HTML template?

eg. <a href="#posts/”>

In other words, why do you need to bind this link in the javascript code at all? What are the advantages/disadvantages of this method?

]]> By: Derick Bailey http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-2496 Derick Bailey Wed, 30 May 2012 21:07:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-2496 I think we're both heading in the same direction and the implementation here is pretty lousy for all the reasons you pointed out. the premise of not using a router to navigate and not using a router as a controller still stand firm, but the implementation and example code in this post is outdated for sure. I've moved well beyond this example code and am doing much more controller-like implementations now, starting with http://lostechies.com/derickbailey/2012/01/02/reducing-backbone-routers-to-nothing-more-than-configuration/ but I've also moved further along with the implementation of modules that i'm using, and having a module-controller per module, which handles all the work flow within a module. i havent' blogged about this yet, but it's something i've been doing in recent apps and i really like the way it works. I think we’re both heading in the same direction and the implementation here is pretty lousy for all the reasons you pointed out. the premise of not using a router to navigate and not using a router as a controller still stand firm, but the implementation and example code in this post is outdated for sure.

I’ve moved well beyond this example code and am doing much more controller-like implementations now, starting with http://lostechies.com/derickbailey/2012/01/02/reducing-backbone-routers-to-nothing-more-than-configuration/

but I’ve also moved further along with the implementation of modules that i’m using, and having a module-controller per module, which handles all the work flow within a module. i havent’ blogged about this yet, but it’s something i’ve been doing in recent apps and i really like the way it works.

]]> By: Brendan Delumpa http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-2495 Brendan Delumpa Wed, 30 May 2012 20:58:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-2495 Derek, I read this article with great interest several months ago. I agree with your overall approach in your final solution, but disagree with using the router as a secondary controller. I know you've cut out a lot of code for brevity, but the way you've coupled the model with the router is a bit disconcerting to me. In lieu of that, an approach I've taken to ensure that I have everything decoupled is to simply have the router trigger an event to which the application controller will respond and update the model(s) which in turn will update the view state. Conversely, a user clicking on a link, does nothing more than either updating its model, or triggering an event that the controller listens to, and it in turn instructs the router to update the URL. In either case, it boils down to a single point of control. So at least from my perspective, the router is simply a composite component with its own MVC within the context of an application controller. Its model being the browser history stack, the controller being the public API of the router, and the view being the URL. That's not to say you can't put all the controller functionality within the router - I've seen that done as well, though not very cleanly - but my personal preference would be to relegate controller function to a custom controller object. In any case, don't know if any of this makes sense, but I've used this pattern with great success. Derek, I read this article with great interest several months ago. I agree with your overall approach in your final solution, but disagree with using the router as a secondary controller. I know you’ve cut out a lot of code for brevity, but the way you’ve coupled the model with the router is a bit disconcerting to me.

In lieu of that, an approach I’ve taken to ensure that I have everything decoupled is to simply have the router trigger an event to which the application controller will respond and update the model(s) which in turn will update the view state. Conversely, a user clicking on a link, does nothing more than either updating its model, or triggering an event that the controller listens to, and it in turn instructs the router to update the URL. In either case, it boils down to a single point of control.

So at least from my perspective, the router is simply a composite component with its own MVC within the context of an application controller. Its model being the browser history stack, the controller being the public API of the router, and the view being the URL.

That’s not to say you can’t put all the controller functionality within the router – I’ve seen that done as well, though not very cleanly – but my personal preference would be to relegate controller function to a custom controller object.

In any case, don’t know if any of this makes sense, but I’ve used this pattern with great success.

]]> By: chandra http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/#comment-2443 chandra Fri, 11 May 2012 09:59:00 +0000 http://lostechies.com/derickbailey/?p=525#comment-2443 This is good, but what about when you have to wait for an asynchronous response when the user submits a form to change view, the router needs to wait for the async success callback to fire before routing to the new view. I read your articles, and I see they are very helpful. Thanks! This is good, but what about when you have to wait for an asynchronous response when the user submits a form to change view, the router needs to wait for the async success callback to fire before routing to the new view. I read your articles, and I see they are very helpful. Thanks!

]]>