GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
...to make NITableViewModel to be subclassed and still work
make NITableViewModelSection accessible to subclasses
make sections public so subclasses can access it
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.
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.
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:
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.
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.
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.
@prime31 @jverkoey Is anyone working on NIMutableTableViewModel or should I start from scratch?
@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.
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.
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.