It’s Hard Out Here for an MVC Advocate

December 6, 2006 at 5:47 pm 5 comments

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.

Entry filed under: cocoa, code, gui, mvc, problems. Tags: .

Worse is Better: Python templating systems vs. Rails ERb mogenerator, or how I nearly abandoned Core Data


  • 1. Chad Weider  |  December 14, 2006 at 3:11 am

    I’ll see what I can do

  • 2. Scott Stevenson  |  December 18, 2006 at 7:46 pm

    but MVC falls apart the moment you have to exit out of Interface Builder to make visual changes to custom widgets

    I don’t think that’s true. Why do you think so?

  • 3. importantshock  |  December 19, 2006 at 6:36 pm


    (First of all, thank you for taking the time to read this.)

    If I’m using an instance of a custom widget inside a .nib file, I should be able to make any visual changes – in the current example, changing the color/type/fill style of a gradient view – without having to add an outlet to my controller and changing its attributes in the awakeFromNib code. Decisions about the appearance of the view should be editable inside Interface Builder by default. Anything else leads to moral degradation and evil. *grin*

  • 4. Scott Stevenson  |  December 24, 2006 at 9:49 pm

    This is inconvenient but I personally don’t think it has anything to do with MVC. It’s just that the code doesn’t have features you want. It sounds like you’ve figured it out, though? To be honest, I don’t have a good feel for the context of what you’re doing, though, so I could be wrong.

    By the way, you have fantastically clear and direct writing style. Keep writing.

  • […] But if we’re sticking to the MVC paradigm (which we are, aren’t we?), one wants to put the initialization code for the EPFoobarMO object inside the EPFoobarMO .m/.h file. + (EPFoobarMO *)foobarWithContext:(NSManagedObjectContext *)context { // According to the docs the object returned is autoreleased return [NSEntityDescription insertNewObjectForEntityForName:@”Foobar” inManagedObjectContext:context]; } But it’s ugly to have to pass the NSManagedObjectContext to the initializer every time. We could stick it inside the app’s controller: – (EPFoobarMO *) foobar { return insertNewObjectForEntityForName:@”Foobar” inManagedObjectContext:[self managedObjectContext]]; } But that’s a flagrant violation of the MVC rules. (Of course, if you’re ignoring them, then this is an ideal solution. But down that way lies Nyarlathotep.) […]

About Me

I'm Patrick Thomson. This was a blog about computer programming and computer science that I wrote in high school and college. I have since disavowed many of the views expressed on this site, but I'm keeping it around out of fondness.

If you like this, you might want to check out my Twitter or Tumblr, both of which are occasionally about code.

Blog Stats

  • 650,315 hits

%d bloggers like this: