Having a list of data object and something visual to represent each, where would you code the sorting/filtering logic? Why?
Edit : All the answers so far are good, but I forgot to add another constraint. What if I don't want to reconstruct the view each time?
I would put in the sorting and filtering methods in the controller, and call these methods from the view.
Your View should only handle displaying the output. Put any filtering/sorting into your business logic and return it to the view.
Depends on the complexity of the sort/filter operation and whether the view control offers those services natively. If the view control offers filtering and it's simply reformatting the in-memory data then leave it in the view. If the sort/filter requires another trip to the data source then keep it all in the controller.
The answer lies in the data. The model delivers the data. If all the data is in the view, the filtering and sorting can be contained within the view. If the data is chunked, the model must deliver the data and contain some of filtering/sorting (the view may still contain filtering/sorting as well).
The controller should not contain these functions, since it is a routing mechanism and should not have any idea of how to interpret the data.
I believe the sorting should be something separate. You should not sort in the model because you want to keep it as-is. Basically, a change in the model implies a re render of the view and you probably do not want that (if you want to animate a transition between the pre and post filter states, for example).
What I would suggest is that the model provides the data to create both a list of visual objects for the view and a sorter object. The sorter object would output a render list which would simply be a list of some identifier linked to the visual objects (index in objects list or other). The order in which the IDs appear represents the order of the sorting and any ID not in the render list is hidden. Every time the view receives a render list, it would update it's display.