如何设计在Backbone.js的控制器? [英] How to design a controller in Backbone.js?

查看:199
本文介绍了如何设计在Backbone.js的控制器?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我感兴趣的是有一个控制器来协调渲染,事件处理,网址导航的路由器和网络访问。类似于一个控制器就在脊柱位: http://spinejs.com/docs/controllers

I am interested in having a controller to coordinate rendering, event processing, URL router navigation and network access. A bit similar to what a Controller does in Spine: http://spinejs.com/docs/controllers

在骨干网的境界,我能找到到目前为止是德里克​​·贝利的一篇文章:<一href=\"http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-$c$c/\" rel=\"nofollow\">http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-$c$c/

In the realm of Backbone, what I could find so far is an article by Derick Bailey: http://lostechies.com/derickbailey/2011/08/28/dont-execute-a-backbone-js-route-handler-from-your-code/

在德里克的code然而,控制器似乎并没有被该航线中使用了。另外,我想知道,如果任何人有更清晰的code例子,显示了具有控制器协调骨干组件的好处是什么?

In Derick's code however, the Controller seems not to be used anymore within the Routes. Also, I was wondering, if anyone has a clearer code example, that shows the benefits of having a Controller coordinating Backbone components?

PS我知道的<一的href=\"https://github.com/marionettejs/backbone.marionette/blob/master/lib/core/backbone.marionette.js#L271-L275\"相对=nofollow>控制器在木偶,但它会很高兴地看到一个骨干code例如没有木偶依赖。

PS I am aware of the Controller in Marionette, but it would be great to see a Backbone code example without the Marionette dependency.

推荐答案

首先,我用Marionette.js,但对于控制器,我用一个简单的对象。

First of all, I use Marionette.js, but for the controller, I use a plain object.

我划分code的应用程序。所以,如果在我的情况,我有一个做笔记的应用程序,我有:

I divide the code for apps. So, if in my case, I have a Note taking app, I have:


  • 记笔记的应用程序

  • 一个应用程序来编辑的类别

  • 进行身份验证的应用程序等。

在一个应用程序,即笔记,我把它在一个RESTful方式。列表,表演等等。

Within an app, i.e notes, I divide it in a RESTful way. List, Show, etc.

例如拍摄名单,我有什么是管理的应用,这部分的控制器。怎么样?

Taking list for example, what I have is a controller to manage this part of the app. How?

沿东西线(你会看到木偶code,但我猜你可以在一个骨干的方式做,但OTOH,我真的建议提线木偶):

Something along the lines (you will see Marionette code, but I guess you can do it in a Backbone way, but otoh, I would really recommend Marionette):

List.Controller =  
  listNotes: ->
    notes = App.request "notes:entities"

    App.execute "when:fetched", notes, =>

      @layout = @getLayoutView()

      @layout.on "show", =>
        @showNotes notes
        @showForm notes

      App.mainRegion.show @layout

  showNotes: (notes) ->
    notesView = @getNotesView notes
    notesView.on "childview:edit:note", (iv, note) =>
      App.vent.trigger "edit:note", notes, note, @layout.formRegion
    @layout.listRegion.show notesView

  showForm: (notes) ->
    App.execute "new:note:view", @layout.formRegion, notes

  getLayoutView: ->
    new List.Layout

  getNotesView: (notes) ->
    new List.Notes
      collection: notes

该控制器是一个普通的JavaScript对象。它所做的是要求集合票据(如果不使用提线木偶,你可以像你想要检索的音符集合)。然后我们等到票据(使用承诺)被取出。

The controller is a plain javascript object. What it does is ask for a collection of notes (if not using marionette, you can retrieve the notes collection like you want). Then we wait until the notes has been fetched (using promises).

当我们有笔记,我们创建一个布局(你可以用你想要的,如果你喜欢的布局想法你有的layoutManager),当布局已经表明,我们展示的笔记列表的形式(输入新注释)。

When we have the notes, we create a layout (you can use what you want and if you like layout idea you have layoutManager), when the layout has been shown, we show the notes list and the form (to enter new notes).

然后,我们的布局添加到所需的区域(同样的layoutManager将工作不提线木偶的用户)。

Then we add the layout to the desired region (again, layoutManager would work for non marionette user).

要显示的笔记中,我们取回我们的观点,我们展示它在该地区所需的显示说明(忽略其他code)。

To show notes, we retrieve our view and we show it in the region desired to show the notes (ignore the other code).

现在使用控制器AKA协调所有的东西的有趣的部分。

Now the interesting part of using a controller AKA coordinating all the stuff.

我们不希望做任何种类的业务工作的意见,如添加注释,删除音符......因此,当我们点击一​​个编辑说明(在列表中查看票据)我们要做的仅仅是触发事件(你可以用骨干code的一行),然后控制器创建自己的事件聚合将监听它,它会做你需要做的编辑笔记内容。就我而言,我泡了管理所有这REST风格的控制器,然后调用编辑控制器在我的应用程序的其他组成部分。该事件的文件。

We don't want the views doing any kind of business work, like add notes, remove notes... So when we click on a edit note (in the list notes view) what we do is just trigger an event (You can create your own event aggregator with one line of backbone code) and then the controller will listen for it and it will do what you need to do to edit notes. In my case, I bubble up the event to a file which manages all this RESTful controllers and then call the Edit Controller in other part of my app.

是我的新的注释做同样的事情,那我泡到我的应用程序的其它部分。

Is the same thing I do for the new note, I bubble it to another part of my app.

所以,控制器,我用控制器来显示我需要为应用程序的一部分,要做到什么看法需要做哪些不属于一个视图,如CRUD操作或转换到其他路线。意见

So, controllers, I use controllers to show the views I need for this part of the app, To do what the views needs to do which doesn't belongs to a view, like CRUD operations or transitions to other routes.

您问到路由器。木偶路由器(对不起,这里我就说说提线木偶)的很大一部分是,我们可以使用普通的对象喂路由器。有什么优势吗?

You asked about router. The good part of Marionette router (sorry, here I will talk about marionette) is that we can use a plain object to feed the router. What are the advantages here?

想象一下:

class NotesApp.Router extends Marionette.AppRouter    
    appRoutes:
      "": "listNotes"

API =
  listNotes: ->
    NotesApp.List.Controller.listNotes()
  newNote: (region, notes) ->
    NotesApp.New.Controller.newNote region, notes, NotesApp.categories
  editNote: (region, notes, note) ->
    NotesApp.Edit.Controller.editNote region, notes, note, NotesApp.categories

App.commands.setHandler "new:note:view", (region, notes) ->
  API.newNote region, notes

App.vent.on "edit:note", (notes, note, region) ->
  API.editNote region, notes, note

App.addInitializer ->
    new NotesApp.Router
      controller: API

(我删除了一些code,所以不要试图挣扎,其中一些PARAMS来自)。

(I deleted some code, so don't try to struggle where some params come from).

这是木偶路由器是使用 API 对象初始化。它的优点是,我可以访问 API 对象从路由器和其它code。

This is a router in Marionette which is initialized using that API object. The advantage is that I can access that API object from the router and from the other code.

所以,当我打的路线,我去了 listNotes 功能齐全,你看到我在那里做。还记得我冒泡的编辑和新的看法?他们停在这里,我在这里听这些事件,我只是叫 API 对象的正常功能。好部分是我决定创造另一条路去到新的形式,我只需要添加路由。在code是存在的,无需改变任何code。

So when I hit that route, I go to the listNotes function and well, you saw what I do there. Remember how I bubbled up the edit and new views? They stop here, here I listen for those events and I just call the proper function in the API object. The good part is I decide to create another route to go to the new form, I just need to add the route. The code is there, no need to change any code.

那么,这结束是一个巨大的反应,但我无法解释到控制器的责任,我给没有这个:P

Well, this ended to be a giant response, but I wasn't able to explain the responsibilities I give to a controller without this :P

作为最后的话,我强烈建议使用木偶,因为只有提供​​良好的东西骨干绝对没有缺点。

As final words, I highly recommend using Marionette because only provides good stuff to backbone with absolutely no drawback.

这篇关于如何设计在Backbone.js的控制器?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆