Re: Listening to bindings
Re: Listening to bindings
- Subject: Re: Listening to bindings
- From: James McConnell <email@hidden>
- Date: Sat, 19 Feb 2005 07:28:20 -0600
On 2/18/05 1:07 PM, "Guy English" <email@hidden> wrote:
> Well I guess the strict "Bad Thing" would be that it evades
> encapsulation. I'm not an OO bigot enough to think that there's never
> a place for that kind of thing but when you start looking for wierd
> hacks to listen to bindings being triggered it's time to re-think the
> situation. That said, we haven't heard back from the original poster
> so maybe he does have a good reason to be doing what he wants to do.
>
> Take care,
> Guy
WARNING: LONG POST
Allow me to briefly explain what my app is and what I'm looking to do. I
could have sworn I'd posted this earlier today, I guess not.
My application is designed to manage a bootleg collection (live audio
recordings). I'm an avid bootleg collector, and want to write a program I
can share with my fellow traders (those that use OS X that is) to manage our
collections.
My thought process is pretty standard, I suppose. My model object "Bootleg"
defines a bootleg. Instance variables include ID#, band name, title, date,
location, media type (CD-R, DVD, VCD) as well as an array of tracks. And I
also have a Track object that has ivars like bootlegID (to track which
bootleg it belongs to in the database), disc number (for multiple disc
shows), track number, name of song, and length of song. These track objects
are stored in the tracks array of the bootleg class.
In my interface, I have two tables, one above the other. The top table
displays each bootleg, and has an NSArrayController to manage it's array of
bootleg objects. The table underneath displays the tracklisting for the
selected bootleg in the top table, and it has an NSArrayController bound to
the Bootleg ivar array "tracks" to manage the collection of tracks. Through
bindings this is all communicating nicely. I have an AppController that has
an ivar array named bootlegs, and an NSObjectController with its content set
as AppController (see Scott's bindings tutorial discussed previously). In
fact, I'd like to take the time to thank Scott for that wonderful article.
I followed it closely when designing this application model.
Now, it's obvious that I need to save this information to disk in some
fashion. I thought about archiving objects and what not, and I suppose that
it's still an option, but as a collection grows, different lists of
different bands and so on, the objects that I archive will get rather large.
So I opted for a bundable database like SQLite, as I can handle SQL
databases with some ease. Couldn't use something like MySQL or PostgreSQL
as it's never a guarantee that the end user is going to have them installed.
So I needed to bundle the database into the application. It's intended for
a single user to use anyway, so I didn't need any kind of server/client
schema for the database.
But I also need to think of ease of use. I want the user to be able to just
enter information into the tables and have it be taken care of, as far as
storage is concerned, under the hood. I could implement some kind of "Save"
feature, where they do the usual save thing (File -> Save or Cmd-S), but it
would be easiest in the end to have any additions/deletions/changes in the
interface happen simultaneously in the database.
Now, in the old days of glue code, this isn't an issue, since we had to
write out these types of changes by hand, and had immediate access to the
code that handles when a new row is added to the interface, when one is
deleted. We had to write the code ourselves, so if we wanted to do
something more than just the standard operation (as I want to do here), it
wasn't even an issue.
But now in the world of bindings, all that code is taken care of with the
Bindings system, and it has made all of our lives a whole lot easier. But
for this application, I don't want the user to have to worry about whether
or not s/he saved the info to the database. I want it to happen in
real-time so the user doesn't even think about it. In order to do that, I
need to have control, or at least access to, the code that handles modifying
the interface to make it constantly concurrent with the database. MVC says
this should happen with a controller. The database would represent the
model, the interface (tables, etc.) would represent the view. So all this
is happening in my AppController. But with bindings, I don't have access to
the code that handles the interaction between the interface and the model.
Instead of either A) subclassing NSArrayController to gain access to the
appropriate code, or B) scrapping Bindings altogether and doing it the old,
"glue code" way, I figured it would make sense to know when these changes to
the interface/model happen, and do my DB updates at the same time, separate
from the bindings. All I need to know is when something is added (as well
as what), when something is deleted, and when something is changed. If I
can listen for when these things happen, I can leave the bindings system
alone to do it's job, and have my AppController do my DB updates alongside.
Is this thinking flawed? Am I taking the long road around and missing a
shortcut? Should I scrap the whole database idea and just archive the
individual bootleg objects (or put them in an NSDictionary or something
similar, wrap them in an NSData object and archive that)? I thought my
ideas were pretty solid, now I'm not so sure. I do want to thank all of you
for your comments and suggestions. I've saved them all for reference. Even
the "pint" remark. ;-)
James
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden