Re: self registering NSValueTransformer and bindings

FROM : I. Savant
DATE : Thu May 08 13:59:56 2008

>
> 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.

> 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).

> - (id) init
>


  Likewise with this. There's no guarantee this will work as expected 
as your project (and the OS X environment) changes.

  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.

> 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 ...

> 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.

  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. :-)

  I reserve the right to be entirely wrong and eat 'humble pie', but 
still ... simple is best (especially when 'unconventional' is causing 
issues). To put this into perspective, with experience your goal is a 
two-minute job using the approach I mentioned.

  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. Overall, you appear to be fighting 
the frameworks, IMO.

--
I.S.