Copyright ©1998 by AAA+ Software Forschungs- und Entwicklungs Ges.m.b.H. All Rights Reserved.
7 Tips and Tricks
This section explains Joy's more advanced features and points out some potential troublespots.
Teaching delegate methodsMethods intended to be called by another object via the delegate mechanism should always be taught before the call to setDelegate:, to guard against the possibility of the setDelegate: method caching the method implementation. Even if you want to change the implementation of a delegate method later, you should do something like js> [obj setDelegate: nil]
Teaching skills to instances of a class clusterBe aware that it is not safe to teach skills to instances of a class cluster, such as NSArray. That is because teaching a skill to an instance involves dynamically creating a subclass of that instance's class, and subclassing a private subclass inside a class cluster is not supported by Apple. Multiple interpreter issuesWhile simple Joy applications will not need more than the one Joy interpreter instance that is already provided when you choose the New Joy Application menu command in InterfaceBuilder, you can have your application use any number of them by dragging additional interpreter instances off the Joy palette. In addition to those interpreter instances that appear in your application's nib files there is always another interpreter called the main interpreter. In InterfaceBuilder the main interpreter is created when the Joy palette is loaded (the window you get by choosing Command Window... in the Joy menu evaluates your commands in the main interpreter). In a stand-alone application the main interpreter is created by the startup code and eventually sources the main.js file, which in turn causes NSApp to be created and the application's main nib file to be loaded. Every Joy interpreter contains a global variable called mainInterp that points to this main interpreter instance. You can use the main interpreter as a repository for global information that all other interpreter instances in your application should share (everybody can eval code in the main interpreter by calling [mainInterp eval: code]). Another way to access the main interpreter is to tell Joy to substitute any interpreter instance in a nib file with the main interpreter when the nib file is loaded, by checking the appropriate box in the interpreter's InterfaceBuilder inspector. When this box is checked, the interpreter's init file (if any) will in reality be sourced by the main interpreter, and its connection variables will also be created in the main interpreter. When you use this feature, be aware that now the same init file can be sourced more than once by the same interpreter, which is not normally the case. Initialization sequenceAfter any connection variables have been set, the interpreter's init file (if any) is sourced by its awakeFromNib method. JavaScript interpreter init files are kept inside the nib file package and are always named after the interpreter instance in InterfaceBuilder's object view, with the extension .js. If you change the name in the object view, Joy will rename the init file automatically when you double-click on the interpreter object the next time. Be careful to edit the correct version of the file, or your changes will have no effect. Connection variablesWhen you control-drag from a Joy interpreter instance in InterfaceBuilder to any other object, you can then label the connection with a variable name. This tells Joy to set the given global variable in the interpreter to the id of the object when the nib file is loaded. Also, when the connected object does have neither its target nor its action set to something other than nil (0), then Joy sets the target to the object itself, and the action to the selector action:. Joy provides a default implementation of the selector action: in a category of NSObject, which does nothing. The net effect of all this is that you can teach skills action: (and, in some cases, doubleAction:) directly to the GUI object that are performed if it is clicked or double-clicked, but you can still use the standard target-action paradigm of Mac OS X if you prefer that. Remember that all connection variables are global. There is always one global variable called self that points to the current interpreter instance. Do not confuse this global self with the hidden parameter self that points to the target of the current message inside skill implementations. Multiple nib filesIf you are using Joy Developer to build a more complex application, you might want to use multiple nib files, maybe to handle multiple documents. Each of your nib files can contain any number of Joy interpreter instances, and since you cannot draw InterfaceBuilder connections across nib files, it is not immediately obvious how the various interpreters should communicate. There are a number of strategies you can use:
|