Edit: I finally got the Interface Builder palette mentioned herein working. I’ll post a screenshot sometime later. I also cleared up some language.
In the past, I have alluded to the fact that I am a diehard Model-View-Controller advocate. I stay remarkably lax on other issues – I don’t mind breaking encapsulation, enjoy both static and dynamic typing, and even advocate paradigms other than OOP for certain applications. However, when it comes to GUI or web application development, I will defend Smalltalk’s Model-View-Controller paradigm to the death. In my still-inchoate Cocoa application, I’m using Interface Builder for the view, Core Data for the model, and Cocoa Bindings + my own code for the controller.
The problem emerges when I need to use the smattering of custom widgets that I’ve selected. Since creating Interface Builder palettes is so difficult, it’s hard to get people to make them – but MVC falls apart the moment you have to exit out of Interface Builder to make visual changes to your own instances of custom widgets.
Therefore, I am stuck with a hard decision. Do I break the MVC design pattern and make a zillion little subclasses of NSView, in which I stick a whole bunch of initialization code? It would be a lot easier, especially when one considers how hard it is to create an IBPalette.
But it’s so ugly! I don’t want a custom-made NSView subclass for each color CTGradient that I want! And until Chad Weider releases a CTGradientWell (please, please, please, pretty please?) making a PTGradientView will be quite difficult.
Bah. Any comments/help/IB Palettes will be appreciated.