Take the 2-minute tour ×

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;

share|improve this question
I'm not 100% sure I understand what your question is, but perhaps this blog post will point you in a good direction Binding A Collection To A View –  dogenpunk Apr 20 '11 at 14:09
There is a similar question I answered about view granularity: stackoverflow.com/questions/4463136/… –  Julien Apr 22 '11 at 20:46

3 Answers 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


