Are there any generic controller classes?

  • I'm reading the book Cocoa Programming, by Anguish,Buck and Yacktman. It was
    written in 2002. In a section discussing MVC they say that M is mature since
    there is a Foundation framwork and also that V is mature since there is the
    AppKit framework. However C is not mature as it could be. Here's a small
    quote.

    If you are creating a document-centric application, then the various classes
    surrounding the NSDocument class will provide much of the controller logic
    you need. Sadly, in other parts of the controller layer, Cocoa does not yet
    provide much help. … There is no generic "controller framework.... The lack
    of a controller framework is one area that could stand improvement. Note
    that Apple does have some generic controller objects that would help.

    My question is if there has been any improving in this area the last 5 years
    since the book was written.

    Thanks Frank
  • On Sep 2, 2007, at 12:43 AM, Frank Bettger wrote:

    > My question is if there has been any improving in this area the last
    > 5 years
    > since the book was written.
    >
    <http://www.google.com/search?client=safari&rls=en-us&q=cocoa+generi
    c+controller+classes&ie=UTF-8&oe=UTF-8
    >
    <http://developer.apple.com/cgi-bin/search.pl?q=generic+controller+classes+c
    ocoa&num=10&site=default_collection
    >

    mmalc
  • Bindings

    On Sep 2, 2007, at 9:43 AM, Frank Bettger wrote:

    > I'm reading the book Cocoa Programming, by Anguish,Buck and
    > Yacktman. It was
    > written in 2002. In a section discussing MVC they say that M is
    > mature since
    > there is a Foundation framwork and also that V is mature since there
    > is the
    > AppKit framework. However C is not mature as it could be. Here's a
    > small
    > quote.
    >
    > If you are creating a document-centric application, then the various
    > classes
    > surrounding the NSDocument class will provide much of the controller
    > logic
    > you need. Sadly, in other parts of the controller layer, Cocoa does
    > not yet
    > provide much help. … There is no generic "controller framework....
    > The lack
    > of a controller framework is one area that could stand improvement.
    > Note
    > that Apple does have some generic controller objects that would help.
    >
    > My question is if there has been any improving in this area the last
    > 5 years
    > since the book was written.
    >
    > Thanks Frank
  • On 02 Sep 07, at 00:43, Frank Bettger wrote:
    > I'm reading the book Cocoa Programming, by Anguish,Buck and
    > Yacktman. It was
    > written in 2002. In a section discussing MVC they say that M is
    > mature since
    > there is a Foundation framwork and also that V is mature since
    > there is the
    > AppKit framework. However C is not mature as it could be. Here's a
    > small
    > quote.
    >
    > If you are creating a document-centric application, then the
    > various classes
    > surrounding the NSDocument class will provide much of the
    > controller logic
    > you need. Sadly, in other parts of the controller layer, Cocoa does
    > not yet
    > provide much help. … There is no generic "controller framework....
    > The lack
    > of a controller framework is one area that could stand improvement.
    > Note
    > that Apple does have some generic controller objects that would help.
    >
    > My question is if there has been any improving in this area the
    > last 5 years
    > since the book was written.

    That's a rather odd statement for the book to be making. The
    Foundation storage classes (NS[Mutable]Array, et. al.) are only a
    small part of the framework, and certainly aren't a viable substitute
    for a model class in anything but the simplest applications.
    Similarly, AppKit views don't suit the needs of all applications
    either - they're certainly useful, but most applications will need at
    least one subclassed or custom view somewhere.

    Claiming that controllers can be prepackaged in a similar fashion is
    just silly. In most applications, the controllers are where much of
    your application's unique logic will live. These can't be written for
    you!
  • On Sep 2, 2007, at 1:39 AM, Andrew Farmer wrote:

    > Claiming that controllers can be prepackaged in a similar fashion is
    > just silly.
    >
    This turns out not to be the case.

    mmalc
  • On Sep 2, 2007, at 1:39 AM, Andrew Farmer wrote:

    > On 02 Sep 07, at 00:43, Frank Bettger wrote:
    >> I'm reading the book Cocoa Programming, by Anguish,Buck and
    >> Yacktman. It was
    >> written in 2002. In a section discussing MVC they say that M is
    >> mature since
    >> there is a Foundation framwork and also that V is mature since
    >> there is the
    >> AppKit framework. However C is not mature as it could be. Here's a
    >> small
    >> quote.
    >>
    >> If you are creating a document-centric application, then the
    >> various classes
    >> surrounding the NSDocument class will provide much of the
    >> controller logic
    >> you need. Sadly, in other parts of the controller layer, Cocoa
    >> does not yet
    >> provide much help. … There is no generic "controller framework....
    >> The lack
    >> of a controller framework is one area that could stand
    >> improvement. Note
    >> that Apple does have some generic controller objects that would help.
    >>
    >> My question is if there has been any improving in this area the
    >> last 5 years
    >> since the book was written.
    >
    > That's a rather odd statement for the book to be making. The
    > Foundation storage classes (NS[Mutable]Array, et. al.) are only a
    > small part of the framework, and certainly aren't a viable
    > substitute for a model class in anything but the simplest
    > applications. Similarly, AppKit views don't suit the needs of all
    > applications either - they're certainly useful, but most
    > applications will need at least one subclassed or custom view
    > somewhere.
    I would definitely like to see some more support for custom views.
    Especially since Apple is changing their look with every other
    release or so. Instead of having to make new buttons in Photoshop (to
    match Apple's style) it would be nice to be able to draw pieces of
    controls into a custom view (e.g. a beveled edge, or the pill shape
    for Mail's toolbar buttons (not that they should be emulated... but
    you get the point)).

    > Claiming that controllers can be prepackaged in a similar fashion
    > is just silly. In most applications, the controllers are where much
    > of your application's unique logic will live. These can't be
    > written for you! _______________________________________________
    What about Bindings with NSObjectController, NSArrayController, etc... ?

    Thanks,
    Jon
  • Just to clarify a possibly misleading paraphrase from
    the start of this thread, here is the actual text:

    Excerpt starting on Page 129 in "Cocoa Programming"
    ISBN 0-672-32230-7

    MVC in Cocoa
    By making this separation into three layers, an
    application’s interface and internal
    data structures are decoupled. As a result, the
    potential for object reuse between
    applications is enhanced. A generic view object, such
    as a text field, could be created
    and then reused in many different, unrelated
    applications. A model could be used in
    different applications that provide different ways to
    access or modify the model’s
    data. For example, perhaps you have a desktop
    application for manipulating some
    data and a secondary command line or Web interface
    that allows access to the same
    data. Just like generic-view classes and
    specialized-model classes can be reused,
    generic-controller classes can also be reused across
    unrelated applications.

    The Foundation Kit offers many data structures that
    provide a basis upon which a
    model can be built. This allows you to concentrate on
    what makes your model
    special as opposed to reimplementing yet another
    standard data structure. In theory,
    this layer is where most of your code-writing time
    should be spent because the
    model is the part of your application, which makes it
    truly unique.

    Cocoa supplies a wide variety of views in the
    Application Kit, therefore, many appli-
    cations will not need to create their own custom
    views. This is a huge time saver,
    and one of the ways that Cocoa can improve your
    productivity.

    If you are creating a document-centric application,
    then the various classes surround-
    ing the NSDocumentclass will provide much of the
    controller logic you need. The
    NSDocumentclass is described in Chapter 9,
    “Applications, Windows, and Screens.”
    Sadly, in other parts of the controller layer, Cocoa
    does not yet provide much help.
    The Application Kit focuses on the view layer, whereas
    the Foundation Kit focuses on
    the model. There is no generic “controller framework.”

    The lack of a controller framework is one area that
    could stand improvement. Note
    that Apple does have some generic controller objects
    that would help. They are in
    the EOInterface framework, which is a part of the
    Enterprise Objects Framework.
    Unfortunately, this is not a part of Cocoa, so it
    isn’t something every Cocoa devel-
    oper can use. Perhaps sometime in the future these
    classes, or something similar to
    them, will become a part of Cocoa.

    Until that time, however, there is no controller
    framework that is a part of Cocoa
    itself. As a result you will often spend time writing
    code for your application’s
    controller layer. Most developers don’t design and
    create reusable, generic-controller
    classes because it is difficult to do well and takes
    much more time to create the
    objects. Few developers have the time and resources to
    “do it right,” so most Cocoa
    application developers create their own controller
    classes each time. This is reason-
    able, especially given the time constraints of most
    projects. Unfortunately, very few
    of these custom classes are reusable from one
    application to the next.

    --------------------------------

    Indeed, as "Cocoa Programming" was being written,
    Apple was busy developing the KVC/KVO controllers and
    bindings technology in Cocoa.  They qualify as
    "something similar" to EOInterface even though there
    are certainly important differences.
previous month september 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today