Why use NSObjectController?

  • This is something I still don't quite understand: Why should I bind to
    an NSObjectController bound to an object, instead of just binding to
    the object itself? Say for instance that I bind the values of a bunch
    of controls to [File's Owner].value1, [File's Owner].value2, [File's
    Owner].value3.... Should I be using an NSObjectController bound to
    File's Owner, and then bind the controls to the object controller? If
    so, why?

    What if I instead bound the controls to [File's Owner].someObj.value1,
    [File's Owner].someObj.value2, [File's Owner].someObj.value3, etc.?
    Malcolm briefly alludes to created an NSObjectController bound to
    [File's Owner].someObj and then binding the controls to [Object
    Controller].value[N] instead. Why would I do this though? Simply for
    brevity?

    What is it that NSObjectController offers me?

    Thanks!

    --
    Seth Willits
  • On Aug 10, 2008, at 10:23 PM, Seth Willits wrote:
    > What is it that NSObjectController offers me?

    Great question. You are on the long steep ascent to Bindings
    understanding. For me the top is still way up there shrouded in clouds.

    I'll take a stab at answering your question:

    1) NSObjectController fits in with Core Data
    2) It works with a managed object context to give you undo and redo
    for "free"
    3) It's subclasses are perhaps more handy, e.g. NSArrayController.

    Notice my answer contains no detail whatsoever. I still have much to
    learn.

    There's actually a good & useful sample using NSObjectController, http://developer.apple.com/samplecode/DepartmentAndEmployees/listing12.html

    Cheers,
    Graham.
  • I don't use CoreData.  Frankly, the main use I have made of
    NSObjectController is to decrease my typing in IB bindings.  For example, my
    inspectors have a large number of controls that are bound through a fairly
    long chain of references to their controllers.  By using an
    NSObjectController to handle the long chain, my individual bindings are much
    shorter.  Your mileage may vary.

    On 8/10/08 11:29 PM, "<cocoa-dev-request...>"
    <cocoa-dev-request...> wrote:

    > On Aug 10, 2008, at 10:23 PM, Seth Willits wrote:
    >> What is it that NSObjectController offers me?
    >
    > Great question. You are on the long steep ascent to Bindings
    > understanding. For me the top is still way up there shrouded in clouds.
    >
    > I'll take a stab at answering your question:
    >
    > 1) NSObjectController fits in with Core Data
    > 2) It works with a managed object context to give you undo and redo
    > for "free"
    > 3) It's subclasses are perhaps more handy, e.g. NSArrayController.
    >
    > Notice my answer contains no detail whatsoever. I still have much to
    > learn.
    >
    > There's actually a good & useful sample using NSObjectController,
    > http://developer.apple.com/samplecode/DepartmentAndEmployees/listing12.html
    >
    > Cheers,
    > Graham.

    G. Apple
  • On Aug 10, 2008, at 9:39 PM, Gordon Apple wrote:

    > I don't use CoreData.  Frankly, the main use I have made of
    > NSObjectController is to decrease my typing in IB bindings.  For
    > example, my
    > inspectors have a large number of controls that are bound through a
    > fairly
    > long chain of references to their controllers.  By using an
    > NSObjectController to handle the long chain, my individual bindings
    > are much
    > shorter.  Your mileage may vary.

    So far that's the only use I've found for it. :)

    It seems like it's really there just as somewhat of an abstract base
    class for the other controllers, but then I wonder why the
    CurrencyConverter example uses it, because it works perfectly fine by
    simply binding directly to the Converter object itself.

    --
    Seth Willits
  • On Aug 10, 2008, at 8:23 PM, Seth Willits wrote:

    > What is it that NSObjectController offers me?
    >
    An implementation of the NSEditor and NSEditorRegistration protocols.

    mmalc
  • On Aug 10, 2008, at 9:54 PM, mmalc crawford wrote:

    >> What is it that NSObjectController offers me?
    >>
    >
    > An implementation of the NSEditor and NSEditorRegistration protocols.

    Ah.

    Now I'll just have to figure out when I'd want to use those...

    --
    Seth Willits
  • On Aug 10, 2008, at 10:08 PM, Seth Willits wrote:

    > On Aug 10, 2008, at 9:54 PM, mmalc crawford wrote:
    >
    >>> What is it that NSObjectController offers me?
    >>>
    >> An implementation of the NSEditor and NSEditorRegistration protocols.
    > Ah.
    > Now I'll just have to figure out when I'd want to use those...
    >
    Any time you want to ensure that pending edits in the view layer are
    committed to your underlying model objects -- for example, if the user
    has entered a new value in a text field then saves a document before
    "exiting" the field (and causing the change to be committed).

    mmalc
  • On Aug 10, 2008, at 10:14 PM, mmalc crawford wrote:

    > Any time you want to ensure that pending edits in the view layer are
    > committed to your underlying model objects -- for example, if the
    > user has entered a new value in a text field then saves a document
    > before "exiting" the field (and causing the change to be committed).

    Ahhhh... That's very useful. I see that Cocoa Bindings Programming
    Topics -> How Do Bindings Work -> The Supporting Technologies in
    Detail -> NSEditor/NSEditorRegistration attempts to mention that. It's
    not quite as clear as your single sentence though. :-)

    Thanks!

    --
    Seth Willits
  • On 8/10/08 10:08 PM, Seth Willits said:

    >>> What is it that NSObjectController offers me?
    >>
    >> An implementation of the NSEditor and NSEditorRegistration protocols.
    >
    > Now I'll just have to figure out when I'd want to use those...

    I seem to have run into this situation the other day.  Maybe my example
    will help.

    I have a nib with some textfields bound to an ivar in File's Owner.  It
    mostly works fine.  Now I have a push button that reads those ivars and
    performs some computation.  If the user has typed something in the
    textfield but not changed focus, this new value is not yet in the ivar.
    Here the commitEditing method is your friend.  But it seems you can't
    send commitEditing to a textfield.  (Yet the docs say "The NSEditor
    informal protocol is implemented by controllers and user interface
    elements. [...] These methods are typically invoked on user interface
    elements").  I believe I'll need to change those textfields to be bound
    to an NSController subclass.

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • On Aug 11, 2008, at 8:52 AM, Sean McBride wrote:

    > But it seems you can't
    > send commitEditing to a textfield.

    Why? If this was supported, wouldn't it greatly simplify things,
    meaning no need to have a NSController subclass, etc.? This is what
    confuses alot of newbs like me. Not arguing against it, just trying to
    see the motivation behind it.

    Russ
  • But then you'd have to figure out which text field to send it to, and
    whether the command is necessary. NSObjectController takes care of
    that for you.

    On 11 Aug 2008, at 19:05, R.L. Grigg wrote:

    >
    > On Aug 11, 2008, at 8:52 AM, Sean McBride wrote:
    >
    >> But it seems you can't
    >> send commitEditing to a textfield.
    >
    > Why? If this was supported, wouldn't it greatly simplify things,
    > meaning no need to have a NSController subclass, etc.? This is what
    > confuses alot of newbs like me. Not arguing against it, just trying
    > to see the motivation behind it.
    >
    > Russ
previous month august 2008 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 31
Go to today