Re: Correct approach?
Re: Correct approach?
- Subject: Re: Correct approach?
- From: Sven <email@hidden>
- Date: Wed, 27 Jun 2007 17:38:59 +0100
I see. Thanks for the advice. One question I have is about the NSOpenPanel
and controller. Currently I have the add button linked to the
LibraryController which then creates a new book.
Would I, in the correct approach, connect the new Controller class (that
calls NSOpenPanel) to the add button? If so, I have to then send the new
book back to the libraryController (where it is stored in the array and
which is also the tableView's data source), correct?? The new controller
class will also have to call some file handling routines to get some data
out of the files, so it would make sense to separate this fucntionality out
and have the book class as a pure data object.
Cheers
On 27/06/07, Keary Suska <email@hidden> wrote:
on 6/27/07 9:22 AM, email@hidden purportedly said:
> LibraryController - datasource and delegate of an NSTableView which is
> responsible for creating and storing library objects (books) in a
mutable
> array. Details are written to a SQLite database. It handles the addition
of
> books and removal of books and writing/reading to/from database store
>
> Book class - contains the details of each library item. Constructor
should
> call NSOpenPanel to get file details of item to add to library.
>
> I'm wondering if this is the correct solution or whether the database
> operations should be in a separate class and whether the file handling
(via
> NSOpenPanel) shouldn't be part of the book class. Also, should Library
> controller be the datasource AND the delegate of the NSTableView? Any
> further advice appreciated.
Answers to these types of questions typically begin with, "it depends..."
because, well, it depends. You seem to be following an MVC pattern, which
is
very Cocoa-friendly.
Some general advice: if you find that your LibraryController is doing or
needs to be doing more than synchronizing data between the database and
your
UI, you should probably separate out the database access functionality to
a
different class. This isn't really a Cocoa issue as it is a "good OOP"
issue. Also, with the "Book" class, its constructor should probably *not*
call NSOpenPanel. This goes back to the MVC pattern, as well as addresses
extensibility issues. Instead, you would have a controller class that
calls
NSOpenPanel and in turn calls the Book class (instance) method
-initWithFile: or some such. This way, you could also have something like
-initWithDictionary: where you could have a data entry option as well.
Best,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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
--
./Sven
_______________________________________________
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