Re: designing beyond MV and (one) C
Re: designing beyond MV and (one) C
- Subject: Re: designing beyond MV and (one) C
- From: Keary Suska <email@hidden>
- Date: Sun, 13 Jan 2008 10:56:28 -0700
- Thread-topic: designing beyond MV and (one) C
on 1/12/08 3:39 PM, email@hidden purportedly said:
> I'm building a utility to take various types of data and parse them
> according to my settings. I'm looking to have an introductory window
> that asks what type of file the user wants to parse. Then based on
> the response, I open the appropriate window to gather data about the
> file to be handled. Separate interfaces will be used for the
> different types of parsing operations.
>
> In the MVC paradigm, do you typically use a different controller for
> each major interface? Should I have three controllers, one to handle
> each type of parser? Three window controllers, to handle each major
> settings interface?
Not necessarily, if I understand your use of "interface". In the basic MVC
implementation you have one model object to one controller to one or more
views. More complex models may require multiple controllers. For instance,
if one of your model properties is an array, you may need an
NSArrayController to handle the array part, while an NSObjectController
handles the other properties. Apple's recommendation of MVC may want you to
have an intermediary controller (could be the one NSObjectController), but
that doesn't always work well, I have found.
Remember also that the MVC paradigm relates *only* to the GUI, so instead of
looking at how you are parsing data, you would look at at how you will be
displaying data.
So the question to ask are, is the data created by the different parsing
mechanisms different enough that they warrant being represented by different
objects? Further, does each data object require a sufficiently different
display that they warrant being displayed by different interfaces? If both
of these are true, then your app probably requires one model object,
controller, and window per file type.
> What about nib files? I've read that putting everything in separate
> nibs is more efficient in terms of loading time, but for quick and
> dirty apps, it would be nice to be able to use the "one nib has all"
> approach as well. Besides, this is not a time-critical app.
Yes, what you have read is true. If you don't care about the load
time--which means that you don't care whether your potential end users think
your app sucks--then you don't need to be concerned about using only the
main nib for the whole app.
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