Best way to bind an Inspector to iVars/Properties?

  • I'm currently wrestling with how to bind inspector components to the
    variables of an object.  I'm also becoming a Talmudic scholar of the Sketch
    example, although my architecture is substantially different.  (I have to
    actually understand it, not just use it.)

        My Shape objects are not based on subclasses, but on a highly variable
    list of properties.  Structs are currently stored as NSValues, which made
    for easy archiving until I started trying to use keyed archivers.  That and
    other issues have brought up the following considerations.  What is the best
    way to handle structs like NSRect, NSSize, NSPoint and be able to bind my
    inspector to them?

    1.  Store as an NSValue (like I started) and use custom property accessors
    to bind to the components.

    2.  Create my own NSObject-based classes for these structs

    3.  Create a proxy holder class for these structs (with accessors)

    4.  Store all components in my props dictionary as individual NSNumber
    components

    5.  Store components in their own dictionary within my props dictionary

    6.  Give up on structs in my props dictionary and use separate iVars with
    component accessors (i.e, the Sketch approach)

    7.  Something entirely different

    8.  Find a new career which pays better with shorter hours

        Any thoughts or experiences?
  • Hey Gordon -

    I usually keep the iVar as a struct and then make getters and setters
    for the exposed values of the structure. For example: I would have
    struct that is an NSRect named frame and a method frameWidth then I
    would bind to frameWidth.

    Good Luck -
    Jon Hess

    On Dec 7, 2007, at 8:53 AM, Gordon Apple <ga...> wrote:

    > I'm currently wrestling with how to bind inspector components to
    > the
    > variables of an object.  I'm also becoming a Talmudic scholar of the
    > Sketch
    > example, although my architecture is substantially different.  (I
    > have to
    > actually understand it, not just use it.)
    >
    > My Shape objects are not based on subclasses, but on a highly
    > variable
    > list of properties.  Structs are currently stored as NSValues, which
    > made
    > for easy archiving until I started trying to use keyed archivers.
    > That and
    > other issues have brought up the following considerations.  What is
    > the best
    > way to handle structs like NSRect, NSSize, NSPoint and be able to
    > bind my
    > inspector to them?
    >
    > 1.  Store as an NSValue (like I started) and use custom property
    > accessors
    > to bind to the components.
    >
    > 2.  Create my own NSObject-based classes for these structs
    >
    > 3.  Create a proxy holder class for these structs (with accessors)
    >
    > 4.  Store all components in my props dictionary as individual NSNumber
    > components
    >
    > 5.  Store components in their own dictionary within my props
    > dictionary
    >
    > 6.  Give up on structs in my props dictionary and use separate iVars
    > with
    > component accessors (i.e, the Sketch approach)
    >
    > 7.  Something entirely different
    >
    > 8.  Find a new career which pays better with shorter hours
    >
    > Any thoughts or experiences?
  • Howdy!

    I think option 9 is the best:

    9. Just use NSRect as the ivar.

    Example code:

    @interface MyController : NSObject {
        NSRect test;
    }

    @property NSRect test;

    @end

    @implementation MyController

    @synthesize test;

    - (void)awakeFromNib {
        [self addObserver:self forKeyPath:@"test"
    options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld
    context:nil];
        self.test = NSMakeRect(2, 3, 4, 2);
        self.test = NSMakeRect(2, 1, 4, 2);
    }

    - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
    change:(NSDictionary *)change context:(void *)context
    {
        NSLog(@"changed %@, %@", object, change);
    }

    @end

    KVO will wrap them in NSValue's for you.

    corbin

    On Dec 7, 2007, at 8:53 AM, Gordon Apple wrote:

    > I'm currently wrestling with how to bind inspector components to
    > the
    > variables of an object.  I'm also becoming a Talmudic scholar of the
    > Sketch
    > example, although my architecture is substantially different.  (I
    > have to
    > actually understand it, not just use it.)
    >
    > My Shape objects are not based on subclasses, but on a highly
    > variable
    > list of properties.  Structs are currently stored as NSValues, which
    > made
    > for easy archiving until I started trying to use keyed archivers.
    > That and
    > other issues have brought up the following considerations.  What is
    > the best
    > way to handle structs like NSRect, NSSize, NSPoint and be able to
    > bind my
    > inspector to them?
    >
    > 1.  Store as an NSValue (like I started) and use custom property
    > accessors
    > to bind to the components.
    >
    > 2.  Create my own NSObject-based classes for these structs
    >
    > 3.  Create a proxy holder class for these structs (with accessors)
    >
    > 4.  Store all components in my props dictionary as individual NSNumber
    > components
    >
    > 5.  Store components in their own dictionary within my props
    > dictionary
    >
    > 6.  Give up on structs in my props dictionary and use separate iVars
    > with
    > component accessors (i.e, the Sketch approach)
    >
    > 7.  Something entirely different
    >
    > 8.  Find a new career which pays better with shorter hours
    >
    > Any thoughts or experiences?
  • I'm not quite sure what you mean about KVO wrapping them in NSValues.

        I'm currently taking the approach of leaving most stuff in my props
    dictionary and adding a lot of properties declarations, mostly with custom
    implementations.  At least it seems to work for the parameters I have bound
    so far.  Some of them are more complex than I would like, and it looks like
    I will also need a significant number of enabler-binding properties.

        I would like to keep my Shape class as a fairly clean data-model object.
    However, I haven't yet figured out a good way to do that other than possibly
    putting all these properties in a category.  I currently use a subclass of
    NSArrayController to handle shape selection.  It is bound to my shapelist
    (i.e., drawlist).  Ideally, I would like to interject something like an
    object controller between the bound shapelist and its component shapes and
    place all the properties complexity there.  Is there currently any way to do
    something like this?  Maybe a statically defined Shape delegate which (as
    shown in Hillegass) routes all unimplemented methods to the delegate?

        The Shape props dictionary is intended to be very flexible, which is why
    I prefer to avoid ivars.  I'm trying to figure out an architecture that
    would easily allow later addition of new properties such as new media types,
    animation, connections, actions, etc.

    > Howdy!
    >
    > I think option 9 is the best:
    >
    > 9. Just use NSRect as the ivar.
    >
    > Example code:
    >
    > @interface MyController : NSObject {
    > NSRect test;
    > }
    >
    > @property NSRect test;
    >
    > @end
    >
    >
    > @implementation MyController
    >
    > @synthesize test;
    >
    > - (void)awakeFromNib {
    > [self addObserver:self forKeyPath:@"test"
    > options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld
    > context:nil];
    > self.test = NSMakeRect(2, 3, 4, 2);
    > self.test = NSMakeRect(2, 1, 4, 2);
    > }
    >
    > - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
    > change:(NSDictionary *)change context:(void *)context
    > {
    > NSLog(@"changed %@, %@", object, change);
    > }
    >
    > @end
    >
    > KVO will wrap them in NSValue's for you.
    >
    > corbin
    >
  • On Dec 8, 2007, at 2:33 PM, Gordon Apple wrote:

    > I'm not quite sure what you mean about KVO wrapping them in
    > NSValues.
    >
    Please read the Key-Value Coding Programming Guide...

    mmalc
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