Re: Core Data in a framework ?
-
Hi
I apologize if this topic has already been discussed elsewhere.
Nobody else has replied yet so perhaps can summarize more briefly the
whole thing:
> NSMutableArray* dates;
> NSMutableArray* emails;
>
> [self bind:@"dates" toObject:itemsController
> withKeyPath:@"arrangedObjects.date" options:nil];
> [self bind:@"emails" toObject:itemsController
> withKeyPath:@"arrangedObjects.email" options:nil];
Why is a binding to arrayController.arrangedObjects.itemKey only a 1-
way binding?
Can i bind to the above keypath somehow bidirectionally ?
I understand i might use an entity relationship in core data to
acheive a similar result.
If use Core Data, then can my class be part of a framework ?
> From: dreamcat7 <dreamcat7...>
> Date: 17 September 2008 16:25:56 BST
> To: "Cocoa-Dev (Apple)" <cocoa-dev...>
> Subject: Binding to an NSArrayController however binding is 1-way
> only.
>
>
> Hello,
>
> I am stuck finding a solution for my array of arrays problem. - A
> problem with a twist !
>
> For the data must be displayed in an NSTableView and therefore it
> must be structured in a particular way.
> Mutable array of [items] with keypaths in each item making up the
> columns of each row.
>
> NSArrayController --[Points to]----> NSMutableArray* items [of
> type Item] (*master array)
>
> Each Item ------>: {
> NSDate* date,
> NSString* email,
> float,
> NSMutableData,
> (id)context,
> etc...
> }
>
> Whole thing (apart from the tableview itself) Is housed within a
> library class. That is to say a framework.
>
> I cannot expose my Items class to the outside world: it will almost
> certainly have one or more hidden fields, the array of item is just
> too unweildy and complicated to be used in the constructor function
> for my class. At this point i would like to re0think my data design
> however the real constraint is the NSTableView class because its
> just so damn finnicky! NSTableView will only accept the one same
> NSArrayController for all of its columns.
>
> So for my constructor function i bind flat representations to (some
> of) the keys. Each column becomes its own NSMutableArray.
>
> NSMutableArray* dates;
> NSMutableArray* emails;
> etc...
>
> [self bind:@"dates" toObject:itemsController
> withKeyPath:@"arrangedObjects.date" options:nil];
> [self bind:@"emails" toObject:itemsController
> withKeyPath:@"arrangedObjects.email" options:nil];
>
> This means i can for a pretty standard array of objects (dates
> emails contexts, etc.) the client using my class can provide easily
> the data needed into the constructor function. What could be simpler
> than an array of NSString ?
>
> I understand that wich Core Data maybe the problem can be overcome
> by specifying relationships (and more easily model differen view of
> the data). However i cannot use Core Data because its for a library
> class which must be packaged in a framework. Am i mistaken about
> this - core data being unsuitable for use in a framework ?
>
>
> Looking at where i am stuck now, its with binding to my
> arraycontroller at the keypath "arrangedObjects.date" and
> "arrangedObjects.email". These rather special binding seems to be
> only 1-way. If i put data into the items array (the master array) it
> will appear in the dates. If i put data in the array of NSDate*
> dates or NSString* emails then the array controller cannot do
> anything. There may not be an items yet existing at that index !
>
> Continuing along my current road looks pretty rocky. Without the
> extra help i need from the arrayController.
> This is how i am currently going about it:
>
> I observe the whole dates array, the emails array, and detect
> whenever they change. If the original data in the master items array
> is not the same (as the new dates array, or emails array).... I have
> to check it wasnt simply because of the 1-ways binding, (and if not
> then find which date or email was added / removed / changed ). Then
> must propagate the change back to the master array the missing data.
> I got that all working however when the arrays are sorted then its
> really a mess to figure out which object was what, and you can
> imagine that any of the array can be sorted at any time... Easily
> an endless loop of changing, observing , and so it would be really
> great to get out of that way of doing things.
>
>
> Is there a more straightforward method for representing such data
> and to update with binding a sorted NSArrayController ?
> ( still remaining as a framework implementation and compatible with
> nstableview ?? )
>
> Any help really appreciated thank you !
>
>
-
On Sep 17, 2008, at 14:24, dreamcat7 wrote:
>> NSMutableArray* dates;
>> NSMutableArray* emails;
>>
>> [self bind:@"dates" toObject:itemsController
>> withKeyPath:@"arrangedObjects.date" options:nil];
>> [self bind:@"emails" toObject:itemsController
>> withKeyPath:@"arrangedObjects.email" options:nil];
>
>
> Why is a binding to arrayController.arrangedObjects.itemKey only a 1-
> way binding?
> Can i bind to the above keypath somehow bidirectionally ?
This has been discussed on this list several times in the last couple
of months.
The short answer is that 'bind:toObject:withKeyPath:options:' doesn't
create a binding. In particular, the first parameter (where you have
@"dates" or @"emails") is not a property key but a binding name. You
need to define a binding of that name before you can use
'bind:toObject:withKeyPath:options:'.
'bind:toObject:withKeyPath:options:' is actually a method in the
NSKeyValueBindingCreation informal protocol, so it's really something
you may implement when defining a new binding, not something you
override.
The confusing part is that NSObject provides a default implementation
of this method, and if you use it with a property key as the first
parameter, you'll get what appears to be a "1-way binding".
The other confusing part is that "creating" a binding is ambiguous.
Sometimes it's used to mean "exposing" a binding -- defining the set
of behaviors that implement a binding of a certain name. Other times
it's used to mean "establishing" a binding -- using a defined binding
of a given name to link two specific objects.
The only documentation I know about for defining new bindings is:
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Con
cepts/HowDoBindingsWork.html
but it's probably not worth doing unless you want to expose the new
bindings as something reusable in IB. -
On Sep 17, 2008, at 2:24 PM, dreamcat7 wrote:
> If use Core Data, then can my class be part of a framework ?
Yes. You can use Core Data in pretty much any situation where you
would use Foundation.
Core Data is not restricted to applications that the user interacts
with. For one example, if you have a Core Data-based document format,
you will need to use Core Data from both your Spotlight importer and
Quick Look generator, not just from your application, to access its
underlying structure.
In a situation like I've described, you could even choose to
encapsulate the basic Core Data-based document format support in a
framework. You could embed this framework in your application wrapper
and link to it from your application, your Spotlight importer, and
your Quick Look generator; doing so is easily possible on Leopard
using the @rpath mechanism.
So don't let the fact that you may not be directly building an end-
user app dissuade you from using Core Data. Anywhere you need to deal
with a graph of model objects, Core Data will be useful.
-- Chris -
Thank you Chris,
Very reassuring to know that its possible, and there was nowhere else
to find this information.
Its not in ADC so I have submitted a request today for Apple to write
documentation on how to do this.
On 18 Sep 2008, at 02:10, Chris Hanson wrote:
> On Sep 17, 2008, at 2:24 PM, dreamcat7 wrote:
>
>> If use Core Data, then can my class be part of a framework ?
>
> Yes. You can use Core Data in pretty much any situation where you
> would use Foundation.
>
> Core Data is not restricted to applications that the user interacts
> with. For one example, if you have a Core Data-based document
> format, you will need to use Core Data from both your Spotlight
> importer and Quick Look generator, not just from your application,
> to access its underlying structure.
>
> In a situation like I've described, you could even choose to
> encapsulate the basic Core Data-based document format support in a
> framework. You could embed this framework in your application
> wrapper and link to it from your application, your Spotlight
> importer, and your Quick Look generator; doing so is easily possible
> on Leopard using the @rpath mechanism.
>
> So don't let the fact that you may not be directly building an end-
> user app dissuade you from using Core Data. Anywhere you need to
> deal with a graph of model objects, Core Data will be useful.
>
> -- Chris
>
