Re: Bindings and object-pointer keys
Re: Bindings and object-pointer keys
- Subject: Re: Bindings and object-pointer keys
- From: Seth Pellegrino <email@hidden>
- Date: Sun, 30 Dec 2007 18:49:55 -0500
Mr. I. Savant,
Thank you for your speedy reply -- I wasn't expecting anyone to be
quite so quick to get back to me. I do have a few questions/
clarifications for you below, if you're willing to indulge me.
Also, in business, a salary is typically not a function of a job
that can have more than one position within a company. What if you
have two "Computer Technicians" and one has been with the company
for a few years while the other just started? If you're not giving
your employees slight raises each year, they're going to quit. How
do you maintain separate scales? Salary is typically assigned to the
employee (your Person instances).
I realize that salaries are typically assigned to people rather than
jobs. This application is a contrived example meant to showcase the
specific difficulty I was having with bindings. I apologize for not
making that clearer in my original email.
You need to define a dependent key. Look up -
setKeys:triggerChangeNotificationsForDependentKey: in the
documentation.
More generally, you need to spend some time with the documentation.
Look up "Key Value Observing" and read all related material. If you
don't understand this, best not to use Bindings or Core Data at all.
They are prerequisite knowledge.
Dependent keys won't help me here. My problem is that a key in the
Person class (namely the job key) is dependent on the keys of another
class (namely the title and salary keys of the Job class). I've read
the Key Value Coding/Observing documentation, and a fair bit of the
Bindings documentation. As yet, I have found no simple way to register
dependent key paths, which is what I need to be able to do.
This is a bad idea for several reasons. I'll touch on the most
relevant: This is poor object-oriented design. There should be a
separate Job class. You don't need to compare equality if you can do
something like this:
(personOne.job == personTwo.job)
Your approach is needlessly complicated, difficult to maintain, and
prone to huge problems if your project gains complexity. Separate
and encapsulate things properly from the beginning and you'll have
far fewer headaches.
Could you elaborate on your meaning? There already is a Job class,
each unique job (as defined by the title) is treated as a singleton
(apologies if that's the wrong word to use).
I realize this may not be the best solution, it's merely the best
solution I've found so far. Conceptually, the problem I'm trying to
solve is this: I have a set of data objects (in this example, People)
with basically a "tag" (a Job). Tags have certain properties (like
titles and salaries). Any of a tag's properties must be trivially
changeable such that every tagged data object will reflect those
changes.
Another potential solution I came up with was to have each tag hold a
mutable array of its associated data objects. Then changing tags for
an object meant simply removing it from one array and adding it to
another, and changing tag attributes only had to be done in one place.
I decided against this approach, though, because I wanted to enable
cross-tag ordering of data objects, and I could see no easy way of
allowing that manipulation.
In general, your model seems as though it could benefit from Core
Data. I strongly recommend checking it out. With proper design, Job
has a to-many relationship to Person and Person has a to-one
relationship to Job. Core Data takes care of this kind of thing
automatically and everything beautifully fits together.
I'm afraid my knowledge of Core Data is rather limited. It seems like
it would work wonders for managing my data model, but I have a few
reservations. Namely, none of the built-in persistent stores meet my
needs. How difficult is it to either query the entire object graph (so
I can write out a file manually) or provide a custom store type? On
the other end, is there a simple way to purge the existing object
graph so it can be read back in programmatically?
More to the point, I'm not entirely sure Core Data would help me
resolve my specific problem. Would changing a person's job's salary
result in change notifications for the person's job? It seems like
it's still the same difficulty with the bindings system, there's just
a different model providing the data which is being bound to.
I look forward to hearing back from you,
Seth Pellegrino
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden