Re: self registering NSValueTransformer and bindings
Re: self registering NSValueTransformer and bindings
- Subject: Re: self registering NSValueTransformer and bindings
- From: Torsten Curdt <email@hidden>
- Date: Thu, 8 May 2008 15:02:05 +0200
On May 8, 2008, at 13:59, I. Savant wrote:
Well, maybe it's language barrier as a non-native speaker ...but in
order for the transformer to do its job it requires a reference to
the NSTabView to be set. And I was trying to inject that reference
through a binding. That's what I wanted to say.
Perhaps, but for clarity, in the Cocoa world there's an important
distinction: IBOutlet and IBAction connections are referred to as
connections. A "binding" refers to the Cocoa Bindings mechanism.
My bad ...always keep thinking if there is a connection it is also
bound. I'll be more specific next time.
That does not seem to be true. But to be 100% sure I've changed it to
NSValueTransformer *theTransformer = [[[MyValueTransformer alloc]
init] autorelease];
...and still get the same behavior. The correct instance is always
a MyValueTransformer and no NSValueTransformer as you said.
I would not have expected that to be the case, but ... :-)
:-)
In
*that* instance, the outlet is nil.
Doh! ...now here I was really stupid. But then again I would think
changing it to
- (void) awakeFromNib
<...>
would solve it. Turns out this is not enough. From looking at the
stacktrace it seems like the framework seems to create another
instance. So the only way I could get it to work was to register
the transformer in the init.
Well no, because the transformer needs to have been registered
before the object graph in the nib is fully realized (because the
connections and bindings that are being (re)established at that
stage will need your transformer).
Yeah ...I would love to learn a bit more about the inner workings of
NIB loading and the object graph establishment. Are there docs on that?
Or can one turn on a flag to get some debugging output for it?
- (id) init
Likewise with this. There's no guarantee this will work as expected
as your project (and the OS X environment) changes.
Hm ...that might be true. Really does depend on the inner workings.
The documentation's example of doing this from within some class's
+initialize method has always worked perfectly for me. I really
suggest you use that approach unless you truly know another will
work. It's one of those things where the behavior (and reasons for
that behavior) depend on a lot of other factors.
But then I would have to inject the reference manually :-/ ...and the
NSTabView is in a differnt NIB and so on. No big deal - but quite
clumsy.
And I think this could be quite neatly be abstracted away if the
transformer had access to the NSTabView. The name of the tab would
be the name of the account type the transformer is mapping to. Not
such a weird idea IMO.
I suppose that's a good argument; I just don't think it buys you
anything in return for the trouble it's causing you ...
Well, I would not have to care about the order of the tabs. No need to
deal with index numbers at all. I think that's a big win for
maintenance.
One thing that is still missing is to get multiple instances
working. So basically getting rid of "NSStringFromClass([self
class])" and replace that with data from the object's interface
builder identity. But somehow I doubt that's easily
accessible ...is it?
This is what I mean - you should really have only one instance.
Every binding you establish references this instance by its
registered name. I may be getting confused by your explanation of
your approach, but it still seems wrong.
Well, I now have a general TabIndexTransformer that finds the correct
tab index from the tab.
- (id)transformedValue:(id)value
{
...
NSArray *items = [tabView tabViewItems];
int i = [items count];
while(i--) {
NSTabViewItem *item = [items objectAtIndex:i];
if ([[item label] isEqualToString:value]) {
return [NSNumber numberWithInt:i];
}
}
...
Right now the NSValueTransformer registration mapping is based on the
class name
TabIndexTransformer -> instance 1 of TabIndexTransformer
but for it be of general value you would need to be able to have
NameA -> instance 1 of TabIndexTransformer
NameB -> instance 2 of TabIndexTransformer
Now the key would need to come from IB ...which instantiates the
transformer.
If you had this "entirely working" by taking a different approach
than usual, I'd graciously bow to you for having found "Another Way"
and I'd shut my trap. However, you're still saying this is mostly-
working-but-not-quite, so I'm pointing out that your somewhat
unconventional approach seems to be the cause of your problems. :-)
Well, it *is* working. At least on 10.5 ...and with the restriction
that you can only have a single instance ...while you probably want to
be able to have different instances for different NSTabViews. So the
question is whether it is possible to get metadata from IB injected
into the created object.
In IB3 there is a "Interface Builder Identity" inspector. I shows
attributes like "Name", "Object ID", "Lock", "Notes". Now if those
attributes were available from the object that has been created by
loading the NIB all would be good. (Like through injection after
creation)
I reserve the right to be entirely wrong and eat 'humble pie', but
still ... simple is best (especially when 'unconventional' is
causing issues).
Right now - no issues. I just want to improve it to "general useful"
To put this into perspective, with experience your goal is a two-
minute job using the approach I mentioned.
True ...but I kind of have a thing for re-usable components ;)
If you're just doing this as a learning experiment, I fully
understand, however it's best to learn the 'usual' way first, then
experiment with other solutions.
Yeah ...well, I got the usual way working. But didn't like it. So now
I am experimenting - also as a learning experiment.
Overall, you appear to be fighting the frameworks, IMO.
Yeah ...I've got that feeling as well sometimes :) I will get there -
please bear with me :)
cheers
--
Torsten
_______________________________________________
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