This pull request does a ton of reorganizing and refactoring to make possible overriding specific behaviors, ultimately removing the need for NSRMap.
The issue that inspired this move: #14.
See the documentation (currently only in NSRRemoteObject.h) for descriptions of each overridable method. I'm also working on a cookbook here with a ton of examples for how to override these methods effectively.
One more thing: CoreData support has moved from being thrown in with NSRRemoteObject to its own class, NSRRemoteManagedObject, a subclass of NSRRemoteObject. So just derive your CoreData classes from that. The NSR_USE_COREDATA thing is still necessary.
I would love feedback on this branch. I think every feature in NSRMap has been covered, (of course with even more flexibility now), so this shouldn't introduce any regression, just some changes. If there are no objections or anything (or, more likely, if no one responds to this issue at all), I'll merge this into Master in the next few days.
dingbat
commented
12 years ago
This pull request does a ton of reorganizing and refactoring to make possible overriding specific behaviors, ultimately removing the need for NSRMap.
The issue that inspired this move: #14.
See the documentation (currently only in NSRRemoteObject.h) for descriptions of each overridable method. I'm also working on a cookbook here with a ton of examples for how to override these methods effectively.
One more thing: CoreData support has moved from being thrown in with NSRRemoteObject to its own class, NSRRemoteManagedObject, a subclass of NSRRemoteObject. So just derive your CoreData classes from that. The
NSR_USE_COREDATAthing is still necessary.I would love feedback on this branch. I think every feature in NSRMap has been covered, (of course with even more flexibility now), so this shouldn't introduce any regression, just some changes. If there are no objections or anything (or, more likely, if no one responds to this issue at all), I'll merge this into Master in the next few days.