Re: Multiple views in a nib file?
Re: Multiple views in a nib file?
- Subject: Re: Multiple views in a nib file?
- From: Graham Cox <email@hidden>
- Date: Tue, 25 Nov 2008 14:02:46 +1100
On 25 Nov 2008, at 4:56 am, Jean-Nicolas Jolivet wrote:
Thanks a lot for your reply! It does help a lot to see how someone
else implemented a similar concept!... I love the multiple
controllers (1 per subclass) / Multiple views (again, 1 per
subclass) idea... I'll try to implement it for my situation as it
seems to be the best way to go...
I should also mention that, in my graphics attributes classes, there
is a certain amount of inheritance going on - they all inherit a
common root class, but some build on others too, for example I have a
basic stroke class, and a number of modified strokes that subclass it.
The controllers follow exactly the same inheritance pattern also, so
each controller class is only implementing the additional or different
parts from its ancestor. The amount of work needed in the controllers
classes is thus kept to a minimum.
In fact, because I'm using KVO most of the key functionality is in the
controller root class and isn't duplicated for the subclasses. To make
this work I leverage -setValue:forKeyPath: in a different way - I have
each controller implement methods that mimics the model object's
methods - in other words they have identical keypaths. In the
controller's case the method sets the relevant control's value, in the
model class it sets the property, as usual. Then, in my KVO observer
method in the root controller class, I just do this (removing some
context-checking code for clarity):
- (void) observeValueForKeyPath:(NSString*) keypath ofObject:(id)
object change:(NSDictionary*) change context:(void*) context
{
id theValue = [change objectForKey:NSKeyValueChangeNewKey];
[self setValue:theValue forKeyPath:keypath];
}
This means each controller subclass just needs to implement a method
for each property it's observing having the same keypath, and the UI
just works. I also override setValueForUndefinedKey: as a no-op so
that if I forget a method the ensuing exception doesn't bring it to a
halt.
Of course bindings takes this idea to its ultimate conclusion, but I
like this way because there's no real hidden magic, other than
setValue:forKeyPath:, and the amount of glue code required is really
small. In fact, one could even eliminate the glue code by adopting a
naming convention for control outlets also, but I currently don't
bother. However, once you have done that you've really reinvented
bindings.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden