Cool thanks! I'll look into those changes. I built this when I was learning iOS on the fly a year or so ago, so I'm sure things aren't all done in the absolute best fashion. I'll learn from your suggestions. Thanks!
Ah, and after re-reading your question. Yes this was a design decision, but I've had to use this same bit within a detail controller inside a split view when I've had more than one table view.
The reasoning here was that search results aren't going to come up that often, so we wanted the results out of the way most of the time to make a cleaner interface.
Per iOS standard design, only one ViewController is supposed to manage a full screen (iPhone) or region of a screen (iPad eg. split view controller). That's because you want to keep the view hierarchy pretty straightforward, instead of taking the view portions of other view controllers and inserting them as subviews of another VC. (Makes you feel dirty). Suggest watching the WWDC 2011 video on Customer Container VC's for an explanation.
Also it would be quite a bit of overkill and extra communication and code to back every table with a full blown view controller.
Yes, if the tableView is your main view. Otherwise you are left rolling your own solution. In the case of the iPad, the tableView is rarely my main view for my controller, so I needed a little more flexible solution.
Hopefully this is useful to someone. Obviously this could also just be a little display helper class (composition > inheritance) or even a category, but this was my original implementation. Might update it in the future. All the crazy coordinate stuff was the painful part.
Actually I realized I can already do this even without plugin functionality. The Item object passed to the sorter has access to the element http://screencast.com/t/Z5uVYNtH8
Sure, but if I only want certain pieces of the view to update when their corresponding model value changes, as opposed to re-rendering the whole view, I have to build an update method that does so. Not horrible in the scheme of things, but awful nice to not build manually. Is Amber.js essentially re-rendering views in their entirely, or is it more precise with its binding updates?
Another difference I suppose would be binding classnames and attributes to your model may require several lines of jQuery to manipulate, vs I believe in amber.js its done by naming convention and an options object (to use different class names).
Cool. I'll give that a whirl. Those rotation bits were a biatch. Thanks for the pointers.