Predicates

  • So, I opened up the Abstract Tree example and that's exactly what I
    want--an outline view that shows all the objects of a given entity
    that have no parents, and that's exactly what Abstract Tree does and I
    see that the "parent == nil" as the fetch predicate is what does that,
    but I'd also like to make it searchable so that when you search for a
    string that's, for example, in a third- or fourth-level child it will
    display that child and any children it has, but none of its parents.
    I can make it do that, but the only way I've been able to get it to
    work is to remove the "parent==nil" in the fetch predicate line, so
    that when the search box is empty it displays all of the objects of
    that entity type, not just the ones with no parents.  Any ideas on how
    to eat my cake and have it too?

    Keith
  • On Dec 26, 2007, at 3:59 PM, Keith Penrod wrote:

    > So, I opened up the Abstract Tree example and that's exactly what I
    > want--an outline view that shows all the objects of a given entity
    > that have no parents, and that's exactly what Abstract Tree does and
    > I see that the "parent == nil" as the fetch predicate is what does
    > that, but I'd also like to make it searchable so that when you
    > search for a string that's, for example, in a third- or fourth-level
    > child it will display that child and any children it has, but none
    > of its parents.  I can make it do that, but the only way I've been
    > able to get it to work is to remove the "parent==nil" in the fetch
    > predicate line, so that when the search box is empty it displays all
    > of the objects of that entity type, not just the ones with no
    > parents.  Any ideas on how to eat my cake and have it too?
    >
    Put back the 'parent==nil' predicate when the search box is empty
    (when there's no other predicate).

    mmalc
  • On Dec 26, 2007, at 7:16 PM, mmalc crawford wrote:

    >
    > On Dec 26, 2007, at 3:59 PM, Keith Penrod wrote:
    >
    >> So, I opened up the Abstract Tree example and that's exactly what I
    >> want--an outline view that shows all the objects of a given entity
    >> that have no parents, and that's exactly what Abstract Tree does
    >> and I see that the "parent == nil" as the fetch predicate is what
    >> does that, but I'd also like to make it searchable so that when you
    >> search for a string that's, for example, in a third- or fourth-
    >> level child it will display that child and any children it has, but
    >> none of its parents.  I can make it do that, but the only way I've
    >> been able to get it to work is to remove the "parent==nil" in the
    >> fetch predicate line, so that when the search box is empty it
    >> displays all of the objects of that entity type, not just the ones
    >> with no parents.  Any ideas on how to eat my cake and have it too?
    >>
    > Put back the 'parent==nil' predicate when the search box is empty
    > (when there's no other predicate).
    >
    > mmalc
    >

    Unfortunately, I don't know how to do that during runtime.
  • On Dec 26, 2007, at 7:35 PM, Keith Penrod wrote:

    >> Put back the 'parent==nil' predicate when the search box is empty
    >> (when there's no other predicate).
    >
    > Unfortunately, I don't know how to do that during runtime.
    >
    How are you updating the predicate at the moment?  You should be able
    to ad a check to that method.

    mmalc
  • On Dec 26, 2007, at 8:49 PM, mmalc crawford wrote:

    >
    > On Dec 26, 2007, at 7:35 PM, Keith Penrod wrote:
    >
    >>> Put back the 'parent==nil' predicate when the search box is empty
    >>> (when there's no other predicate).
    >>
    >> Unfortunately, I don't know how to do that during runtime.
    >>
    > How are you updating the predicate at the moment?  You should be
    > able to ad a check to that method.
    >
    > mmalc
    >
    In Interface Builder.  I just type it into the "fetch predicate" box
    in the inspector window.  I'm currently trying to figure out how I can
    make an outlet in the controller class that links to the search field
    and tells it to update the fetchPredicate when it notices a change in
    the search box, but I'm not sure how to do that.
  • On Dec 26, 2007, at 8:14 PM, Keith Penrod wrote:

    > In Interface Builder.  I just type it into the "fetch predicate" box
    > in the inspector window.  I'm currently trying to figure out how I
    > can make an outlet in the controller class that links to the search
    > field and tells it to update the fetchPredicate when it notices a
    > change in the search box, but I'm not sure how to do that.
    >
    Sorry, but this shows precisely why it's important to learn Cocoa's
    design patterns etc. in an ordered fashion.  If you start to try to
    use frameworks that are labeled as "advanced" without having mastered
    the basics, then you won't know where or how to customise your
    application...

    There are two ways to set up the search field, using target-action or
    using bindings (see <> and <<A href="http://developer.apple.com/documentation/Cocoa/Reference/CocoaBindingsRef/Concepts/BindingTypes.html#//apple_ref/doc/uid/20002305-216985">http://developer.apple.com/documentation/Cocoa/Reference/CocoaBindingsRef/C
    oncepts/BindingTypes.html#//apple_ref/doc/uid/20002305-216985
    > respectively).

    In either case, you can implement the set accessor method (that's
    invoked when the search field changes) to update the tree controller's
    fetch predicate accordingly (you need an outlet to the controller,
    then send it setFetchPredicate: <http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Cla
    sses/NSObjectController_Class/Reference/Reference.html#//apple_ref/occ/inst
    m/NSObjectController/setFetchPredicate:
    >).  If there's no predicate associated with the search field, then
    the predicate should be "parent==nil", otherwise it's whatever is in
    the search field.  You can then re-fetch the tree controller's content
    (<http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Cla
    sses/NSObjectController_Class/Reference/Reference.html#//apple_ref/occ/inst
    m/NSObjectController/fetch:
    >).

    mmalc
  • On Dec 26, 2007, at 9:40 PM, mmalc crawford wrote:

    >
    > On Dec 26, 2007, at 8:14 PM, Keith Penrod wrote:
    >
    >> In Interface Builder.  I just type it into the "fetch predicate"
    >> box in the inspector window.  I'm currently trying to figure out
    >> how I can make an outlet in the controller class that links to the
    >> search field and tells it to update the fetchPredicate when it
    >> notices a change in the search box, but I'm not sure how to do that.
    >>
    > Sorry, but this shows precisely why it's important to learn Cocoa's
    > design patterns etc. in an ordered fashion.  If you start to try to
    > use frameworks that are labeled as "advanced" without having
    > mastered the basics, then you won't know where or how to customise
    > your application...
    >
    > There are two ways to set up the search field, using target-action
    > or using bindings (see <http://developer.apple.com/documentation/Cocoa/Conceptual/SearchFields/Arti
    cles/ConfiguringTargetAction.html#//apple_ref/doc/uid/20002073
    > > and <http://developer.apple.com/documentation/Cocoa/Reference/CocoaBindingsRef/C
    oncepts/BindingTypes.html#//apple_ref/doc/uid/20002305-216985
    > > respectively).
    >
    > In either case, you can implement the set accessor method (that's
    > invoked when the search field changes) to update the tree
    > controller's fetch predicate accordingly (you need an outlet to the
    > controller, then send it setFetchPredicate: <http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Cla
    sses/NSObjectController_Class/Reference/Reference.html#//apple_ref/occ/inst
    m/NSObjectController/setFetchPredicate:
    > >).  If there's no predicate associated with the search field, then
    > the predicate should be "parent==nil", otherwise it's whatever is in
    > the search field.  You can then re-fetch the tree controller's
    > content (<http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Cla
    sses/NSObjectController_Class/Reference/Reference.html#//apple_ref/occ/inst
    m/NSObjectController/fetch:
    > >).
    >
    > mmalc
    >

    I'm sorry, but that is the entire reason I never read Apple's
    documentation.  The article about target-action doesn't say anything
    at all about how to configure the search box, only that it's something
    you should do.  I've already set up the binding properly, so the
    search box works fine--but only when it's non-empty.  If I could
    figure out a way to make the search box actually do something when
    it's empty or figure out where I need to implement this action that's
    apparently notified when the search field changes, then I'd be great.
    But that's exactly what I have no idea how to do, and none of the
    articles listed say anything about that.

    Keith
  • Hi Keith,

    The search field documentation doesn't explain the concept of
    target-action inline because it's one of a small number of patterns
    that underly all of Cocoa.

    See "The Target-Action Mechanism",
    <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
    /CommunicatingWithObjects/chapter_6_section_5.html#//apple_ref/doc/uid/TP40
    002974-CH7-SW14
    >.

    You will not likely have much luck with Cocoa programming until you've
    read the "Communicating With Objects" section of the Cocoa
    Fundamentals guide, which is the section that contains the section on
    target-action.  The rest of the docs assume you understand the
    fundamentals.

    It's short. :-)

    -Ken

    On Dec 27, 2007 11:09 AM, Keith Penrod <keith.penrod...> wrote:
    >
    >
    > On Dec 26, 2007, at 9:40 PM, mmalc crawford wrote:
    >
    >>
    >> On Dec 26, 2007, at 8:14 PM, Keith Penrod wrote:
    >>
    >>> In Interface Builder.  I just type it into the "fetch predicate"
    >>> box in the inspector window.  I'm currently trying to figure out
    >>> how I can make an outlet in the controller class that links to the
    >>> search field and tells it to update the fetchPredicate when it
    >>> notices a change in the search box, but I'm not sure how to do that.
    >>>
    >> Sorry, but this shows precisely why it's important to learn Cocoa's
    >> design patterns etc. in an ordered fashion.  If you start to try to
    >> use frameworks that are labeled as "advanced" without having
    >> mastered the basics, then you won't know where or how to customise
    >> your application...
    >>
    >> There are two ways to set up the search field, using target-action
    >> or using bindings (see <http://developer.apple.com/documentation/Cocoa/Conceptual/SearchFields/Arti
    cles/ConfiguringTargetAction.html#//apple_ref/doc/uid/20002073
    > > > and <http://developer.apple.com/documentation/Cocoa/Reference/CocoaBindingsRef/C
    oncepts/BindingTypes.html#//apple_ref/doc/uid/20002305-216985
    > > > respectively).
    >>
    >> In either case, you can implement the set accessor method (that's
    >> invoked when the search field changes) to update the tree
    >> controller's fetch predicate accordingly (you need an outlet to the
    >> controller, then send it setFetchPredicate: <http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Cla
    sses/NSObjectController_Class/Reference/Reference.html#//apple_ref/occ/inst
    m/NSObjectController/setFetchPredicate:
    > > >).  If there's no predicate associated with the search field, then
    >> the predicate should be "parent==nil", otherwise it's whatever is in
    >> the search field.  You can then re-fetch the tree controller's
    >> content (<http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Cla
    sses/NSObjectController_Class/Reference/Reference.html#//apple_ref/occ/inst
    m/NSObjectController/fetch:
    > > >).
    >>
    >> mmalc
    >>
    >
    > I'm sorry, but that is the entire reason I never read Apple's
    > documentation.  The article about target-action doesn't say anything
    > at all about how to configure the search box, only that it's something
    > you should do.  I've already set up the binding properly, so the
    > search box works fine--but only when it's non-empty.  If I could
    > figure out a way to make the search box actually do something when
    > it's empty or figure out where I need to implement this action that's
    > apparently notified when the search field changes, then I'd be great.
    > But that's exactly what I have no idea how to do, and none of the
    > articles listed say anything about that.
    >
    > Keith
    >
  • On Dec 27, 2007, at 11:49 AM, Ken Ferry wrote:

    > The rest of the docs assume you understand the
    > fundamentals.

      This seems to be the part that people have a lot of trouble with.
    It reminds me of a recurring problem that pops up every other month it
    seems.

      Now and again a user will write to complain that the Help Book for
    one of my apps is "worthless", etc. They cite lines like this:

      "To export the selected item as a Microsoft Word document, drag the
    item from the list into the Finder. A Word document will be created in
    the location to which the item was dragged."

      Invariably, it's not-so-savvy users who complain that the manual
    doesn't tell them 1) what the Finder is, 2) how to open a new Finder
    window to the folder of their choice, and 3) how to position the
    windows so that both are visible for the drag.

      They don't like being told they must be familiar with "the basics"
    because they view it as insulting. After all, the manual should give
    precise instructions, right? The few times users pursued the argument,
    I asked them at what level of detail should the documentation stop?
    Should it include a copy of the OS X Help Book? Finder's? Should it
    document how to "drag" things? Should it go on to explain how to use
    the mouse to do so? How to plug in the mouse? Of course not. It makes
    sense only for the documentation about "Application X" to include
    instructions for using "Application X", not the Finder, OS X, or the
    computer. There are other Help Books for that and it's up to the user
    to read them.

      The bottom line is that all documentation and reference material
    require at least some skill at using reference material in general.
    It's up to you to recognize an unfamiliar topic referenced by the
    current documentation you're reading and look it up and cross-
    reference it. This is not specific to the Cocoa documentation; it's
    how learning works.

      In short, mmalc and Ken are absolutely correct: you *must* learn
    the basics. You may have gotten pretty far building your app using
    Bindings, but you're getting hung up on one of the most basic and
    important bits of prerequisite knowledge and there is quite simply no
    way around your problem short of finding someone else to do it for you
    (who subsequently *has* read what you need to read).

      None of this is meant to be rude, but simply the hard reality. You
    must read, read, read.

    --
    I.S.
  • On Dec 27, 2007, at 9:20 AM, I. Savant wrote:

    > None of this is meant to be rude, but simply the hard reality. You
    > must read, read, read.
    >
    And "play" with the API, and look at examples...

    FWIW, I've added a "SearchField" example to <http://homepage.mac.com/mmalc/CocoaExamples/controllers.html> -- see also the existing "Filtering Controller" example.

    mmalc
  • On 28/12/2007, at 4:20 AM, I. Savant wrote:
    >
    > The bottom line is that all documentation and reference material
    > require at least some skill at using reference material in general.
    > It's up to you to recognize an unfamiliar topic referenced by the
    > current documentation you're reading and look it up and cross-
    > reference it. This is not specific to the Cocoa documentation; it's
    > how learning works.

    Yes, when I did my CS hons year, a large part of it was learning to
    read vendors documentation, mainly Burroughs, really getting into the
    spirit of those systems.

    > In short, mmalc and Ken are absolutely correct: you *must* learn
    > the basics. You may have gotten pretty far building your app using
    > Bindings, but you're getting hung up on one of the most basic and
    > important bits of prerequisite knowledge and there is quite simply
    > no way around your problem short of finding someone else to do it
    > for you (who subsequently *has* read what you need to read).
    >
    > None of this is meant to be rude, but simply the hard reality. You
    > must read, read, read.

    True, true, true

    Ian
previous month december 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
31            
Go to today