Re: [Pyobjc-dev] NIB Validation & action methods

[<bb...@ma...>]

On Saturday, November 16, 2002, at 05:34 PM, Just van Rossum wrote:
> bb...@ma... wrote:
>>> Erm, when is this warning emitted? When the class is instantiated
>>> or when the button is clicked? If the latter: NibLoader could do it
>>> at class-build-time.
>>
>> Neither; when the NIB is loaded and the nib loading mechanism walks
>> through the connections to ensure that the appropriate target/action
>> methods can be connected.
>
> You mean when (eg.) a window is instantiated?

NIB loading basically happens in two passes:

- all objects contained in the object graph within the NIB are 
unarchived (this is an oversimplification -- see the 'deferred' 
functionality on NSWindow -- irrelevant for this discussion, though 
very interesting it is)

- all of the NIB connections are made

The second step is when the validation occurs.  So, it happens after 
instantiation but before the first action is sent.  Through 
-awakeFromNib, the developer is given the opportunity to further edit 
the object graph before the first action is sent.

>> This is the only time that such validation can occur.   Class
>> instantiation is too early as there may be additional methods added
>> to the class between the time the class is created and those methods
>> may contain the action implementations.
>
> Not sure if I get this. What NibLoader could do is, that as soon the 
> module
> containing the class is imported, it verifies the action methods 
> contained in
> the class body actually contain all the methods as specified in the 
> nib. How
> does this compare to what the Cocoa runtime does?

A step back for a second:  The NibLoader.py that exists now doesn't 
really have anything to do directly with NIB loading and has everything 
to do with defining new Objective-C classes.   NibLoader provides the 
developer with an incredible convenience;  the developer no longer has 
to worry about keeping their source files in sync with the reality 
perpetuated by the NIB file.

NIB loading happens much later.

Furthermore, the typical Cocoa application will have a need to user the 
classes that may potentially be defined via NibLoader long before the 
NIB file is actually loaded.   Consider the case of a Preferences 
controller.  The controller may provide API for retrieving and setting 
preferences values that are used application wide.  It may also provide 
various actions/outlets via which it controls the display of 
preferences in a preferences panel.   The preferences controller may be 
instantiated long before the preferences UI is ever displayed (and the 
UI may never be displayed).

In terms of validation, the validation of the target/action connections 
made in a NIB file cannot be made until the NIB file itself is actually 
loaded.   Consider this very bogus example:

 >>> class MyFoo(NSObject): pass
...
 >>> def barAction_(self, sender): print "responding to bar -- %s" % 
sender
...
 >>> MyFoo.barAction_ = barAction_

Now, imagine that the definition of the MyFoo class was the result of 
using NibLoader, which found the MyFoo class in the NIB file.  Sometime 
between the initial definition of the class MyFoo and the loading of 
the NIB file, the developer has added the barAction_() method to MyFoo 
-- in traditional ObjC, this is likely because they loaded an NSBundle 
that contains a category on the MyFoo class that added the additional 
method(s).

This is actually a pretty common situation given the responder chain.  
By simply tossing some action methods into a category on NSApplication 
or NSWindow, then setting the target of a menu item or button to nil 
while setting the action to be the newly added methods, that action can 
be triggered from anywhere in the UI.   Similar tricks can be done to 
add new functionality to every button, every field, every text view, 
every table view, or any other subset of objects.

With python, the ability to derive new methods programmatically and add 
them at will makes it all the more powerful.

In any case, the end result is that the target/action connectivity 
cannot be validated when the class is initially defined as a 
combination of what is found in the NIB and what the developer has 
directly implemented -- there may be new method implementations added 
before the NIB is loaded that will fill in the missing pieces, 
effectively.

b.bum