backbone.js - 视图中的视图和管理事件
组织视图的好方法是什么？假设我有一个 div，它将包含从用户管理面板角度的视图 - 将有一个用户列表以及用于选择一次显示多少个用户的选项、排序选项、要显示的页面、过滤器、等等...
我想要一个包含除表格和数据之外的所有内容的外部视图吗？然后是包含表（以及数据）的内部视图？分页会有自己的视图吗？分页视图如何使用点击事件来更新用户视图？我只是对如何组织视图感到困惑，同时仍然能够让不同的事件触发其他视图到 render() / 集合到 fetch() 。
因此，基本的层次结构如下所示：
- User View
- Table
- List of Users
- Pagination
- List of available numbers to click
- Filters
- Possible filters to apply to the data
然而，单击分页中的过滤器或数字应该能够使集合获取新数据并刷新视图；
What's a good way to organize views? Let's say I have a div that will contain a view from an admin panel perspective of users - there will be a list of users along with options to choose how many to display at a time, sorting options, what page to be on, filters, etc...
Would I want an outside view that contained everything except the table and data? And then an inside view that contains the table (along with the data)? And would the pagination have it's own view? And how would the pagination view use the click event to update the user view? I'm just confused on how to organize the views while still being able to have different events trigger other views to render() / collections to fetch().
So a basic hierarchy would look like:
- User View
- Table
- List of Users
- Pagination
- List of available numbers to click
- Filters
- Possible filters to apply to the data
Yet clicking a filter or number in the pagination should be able to get the collection to fetch() new data and refresh the view;
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我第二个道元朋克。我会有一个用户集合/视图。因为您上面描述的整个层次结构都是关于该用户集合的。它的所有函数都会操纵该集合，然后重新呈现用户视图。
如果您只想为该用户将更改应用到服务器，您可以将第二个用户视图（一个用户）绑定到一个模型。
I second dogenpunk. I would have one User Collection / View. Because the whole hierarchy you describe above is about that one User Collection. All functions of it manipulate that collection and then you rerender the User View.
You could have a second User View, one single User, tied to a Model if you want to apply changes to the server for that user only.
我尝试尽可能地反映我的服务器端 MVC 结构。
所有可以放入插件的东西，我都会这样做，然后将这些插件保存在调用插件的控制器的单独位置。因此，在您的情况下，用户列表的表视图将保存在表插件中，或者可能保存在“用户”模块中（如果它是我实际上只使用一次的代码）。
如果我需要覆盖插件的输出，那么我会将视图存储在模块文件夹中。
我试图避免做的是纯粹按照视图中的 HTML 类型来存储视图，因此我不会将模块的视图存储为“表”，因为如果稍后它更改为列表，这会变得混乱。显然，如果我有一个“表”插件，那么该插件的视图将是一个表，但是更改 JavaScript 视图意味着只需将插件调用从“表”更改为“列表”即可。
I try to reflect my server-side MVC structure as much as I can.
Everything that can be put into a plugin, I do so, and then I keep those plugins in a separate location to the controllers which call the plugins. So in your case, the table view for the list of users would be held either in a table plugin, or possibly in the 'users' module if it was code I was really only going to use once.
If I need to override the output of the plugin, then I store the view inside the module folder.
What I try to avoid doing is storing views purely by the type of HTML inside them, so I wouldn't store a module's view as 'table' because that will get confusing if later it changes to a list. Obviously, if I have a 'table' plugin then the view for that is going to be a table, but then changing the JavaScript view means just changing the plugin call from 'table' to 'list' anyway.
我对你原来的问题有两分钱。如果你真的想让它成为一个 MV*，分页将是一个视图，你的表格将是一个视图。并让您的集合发送（触发）事件来改变您的视图。我会问自己的另一个问题是，当我的收藏发生变化时，会受到什么影响？例如，在您的情况下，我认为集合更改不会直接影响您的 userView，它只会影响表和分页。
My 2 cents to your original question. If you really want to make it a MV*, a pagination would be a view, your table would be a view. And have your collection to send out ( trigger ) events to change your view. And another questions I would ask myself also is what will be affected when my collection changes? For example, in your case, I don't think the collection changes will affect your userView directly, it only affects the Table and Pagination.