Once common way to do this while keeping the view code separate from the model code is to use Objective-C categories. If your managed object subclass were named MyManagedObject
, you would do something like this:
@interface MyManagedObject (ViewSupport)
@property (nonatomic, readonly) NSString* stringForPopUpButton;
@end
@implementation MyManagedObject (ViewSupport)
+ (NSSet *)keyPathsForValuesAffectingStringForPopUpButton
{
return [NSSet setWithObjects:@"firstname", @"userid", nil];
}
- (NSString *)stringForPopUpButton
{
return [NSString stringWithFormat: @"%@, %@", self.firstname, self.userid];
}
@end
This code can appear in a separate file, or whatever. This pattern works well for simple things like combining two properties. For more complex transformations, the logic will usually live in an NSViewController
subclass. The model is typically pushed into these objects using the -representedObject
property and then the accompanying views can be constructed in Xcode/InterfaceBuilder, etc. This pattern keeps the data munging logic coupled with the view/nib/xib that uses it.