Redo of previous request. make sections and NITableViewModelSection public... #127

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
5 participants
Contributor

prime31 commented Dec 10, 2011

...to make NITableViewModel to be subclassed and still work

Owner

jverkoey commented Dec 14, 2011

Allowing means of accessing the model data other than through the data source protocol can lead to abuse of the model, e.g. someone might create a model and then implement the data source protocol in their view controller, returning the internal properties of the model directly.

If you provide a use case for when being able to access these section objects is necessary then we can consider adding methods to the model object that provide this extra functionality without exposing too much information.

Contributor

prime31 commented Dec 14, 2011

The current NITableViewModel system is fully closed and not at all extensible. It can do static models and nothing else. It can't be subclassed in any useful way. The first step to making it useful is to allow subclasses to access the sections. I totally agree that the heavy handed approach of going public here probably isnt the best plan in retrospect. Making the model data be protected would be a better idea.

NITableViewModelSection is even worse. It is internal to NITableViewModel, hidden from subclassing and unavailable to NITableViewModel subclasses completely.

Use cases for all of this are everywhere. Every tableview that isn't static would benefit from having a NITableViewModel subclass running the show. It doesn't make much sense to make people have to make their own base model class and reimplement all the data source methods already in there.

Use case for NITableViewModelSection is again to allow dynamic table views. I also subclassed it to allow UIView's to be used as section headers rather than the of limited use text only headers.

Owner

jverkoey commented Dec 14, 2011

You're spot on about dynamic models. I'd love to provide a robust mutable model object in Nimbus to satisfy this exact need.

A next step could be to create a NIMutableTableViewModel class that subclasses NITableViewModel and implements methods for adding, removing, and rearranging rows. What are your thoughts on this?

Some of the standard use cases for completeness' sake:

  • Prepending and appending content to a model (e.g. twitter feed, infinite scrolling).
  • Deleting a row from a table.
  • Inserting rows into a table (e.g. tapping a cell to expand a group).
  • Reordering rows (e.g. re-arranging tasks in Things).
Contributor

prime31 commented Dec 14, 2011

Yeah, absolutely. The only issue being that NITableViewModel isn't subclassable in it's current state without reimplementing everything including data storage. It accesses its properties using the private _sections instead of through the property making subclassing impossible without reimplementing the whole thing. That was my main reason for going public in there so that I can make a mutable model subclass.

@jverkoey jverkoey closed this in fb3b12e Dec 14, 2011

Owner

jverkoey commented Dec 14, 2011

I've pushed some changes to make it easier to access the internal properties of NITableViewModel. The next step is to decide on the best way to store the internal data as mutable data in the NIMutableTableViewModel subclass.

Contributor

prime31 commented Dec 14, 2011

Sweet! Looks good. I'll integrate these changes into my mutable models and see if I can extract something useful out of it that is nice and generic.

nrw commented Mar 30, 2012

@prime31 @jverkoey Is anyone working on NIMutableTableViewModel or should I start from scratch?

Contributor

alexbell commented Mar 30, 2012

@nrw if you look at my fork i have working append'able sectioned and list models (with examples added to the demo proj). it's a little rough/basic, but gets the job done for just supporting paging.

Contributor

alexbell commented Mar 30, 2012

And if anybody's thinking of starting a truly mutable NITableViewModel, I would love to help out with it. Probably something I would need eventually.

+1

I think this mutable model could help in implementing NITableViewModel together with a NSFetchedResultController.

At the moment the only solution I have found to achieve this is to use the NICellFactory to retrieve the cell from the NSManagedObject, but that is just a static function, I think with a mutable model it could be way better than this.

@jverkoey do you think that a NSFetchedResultsControllerDelegate can drive the content of a NIMutableTableViewModel in an efficient way? I've would like to hear your thought about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment