[Drawkit] Filetype binding mechanism

[Graham Cox]

General Info, but particularly directed at Brad.

The next beta (due any time - should be in the next few days) includes  
a general mechanism to expand the types of files that  
DKDrawingDocument is able to read and write without the need to  
subclass it or hack around with its code. Originally Brad was looking  
to do this as a way to read and write SVG and other file types, and  
his solution was to use the file type string to build a method name  
which was then invoked. Unfortunately this approach suffers from two  
problems - 1. the file name string must be compatible with allowed  
method naming - where the file type is a UTI that is not the case, you  
end up with an illegal method name that contains dots. 2. The string  
concatenation approach doesn't permit the same method to be invoked by  
different file types. This is a much smaller problem because for one  
thing it's not that likely to occur and for another it's easy to  
simply set up two methods, which ultimately call the same one.

Nevertheless the new mechanism solves both of these issues. It's very  
simple too.

An application that wishes to extend the types of files will implement  
the data translation methods as a category of DKDrawing. For file  
import, a class method that accepts NSData and returns a DKDrawing  
instance is required. For file export, a parameterless method that  
returns NSData is required. You can call them whatever you want. Then  
your app needs to register these methods against the file type or  
types the methods work with with the DKDrawingDocument class. The  
methods are:

+ (void)	bindFileImportType:(NSString*) fileType toSelector:(SEL)  
aSelector;
+ (void)	bindFileExportType:(NSString*) fileType toSelector:(SEL)  
aSelector;

The default methods in DKDrawingDocument for - 
readFromData:ofType:error: and -dataOfType:error: now use the  
registered information to look up the method needed and invoke it. The  
standard drawing types are automatically pre-registered so things work  
exactly the same as before for the default situation.

You are still free to subclass DKDrawingDocument or to use some  
entirely different NSDocument class in your app in which case you are  
responsible, as with any Cocoa app, for handling your file I/O as you  
need. It also has no bearing on the plist or filetype to document  
class mapping  that Cocoa does anyway - this is purely a supplementary  
mechanism that extends DKDrawingDocument for the common need of  
handling more file types.

cheers, Graham