Re: designing beyond MV and (one) C
Re: designing beyond MV and (one) C
- Subject: Re: designing beyond MV and (one) C
- From: Daniel Child <email@hidden>
- Date: Tue, 15 Jan 2008 18:40:38 -0500
On Jan 14, 2008, at 4:19 AM, Uli Kusterer wrote:
For the case you mention, it sounds like you could get away with a
pair of controllers or so. The idea is that you have one (generic)
class that encapsulates all the features that all the parsers
expose to the GUI. The GUI, and any of its controllers, only know
how to talk to this generic controller. The actual parsers would
then be subclasses of this generic controller. Only the spot that
opens the file would need to know what type of file it is, and
would create the appropriate subclass.
I didn't think of subclassing from a "generic controller." I thought
that the controllers are the least rewritable code, and therefore not
generally subclassed. Now the model code for the different parsers...
they have enough in common, I think, to justify subclassing.
The rest of the app would just talk to the subclass through the
generic controller's interface. If there is only one window, one
window controller would be enough. If you only have very, very
simple windows, and you don't open several instances of the same
window, you may even get away without a window controller and just
hide and show the windows as needed.
I have been doing the latter, and am still trying to figure out what
advantage there is to a window controller. What can it do that a
regular controller can't, and vice versa....? I'm still failing to
see their whole reason for being in non-document app cases.
You can have one big "master controller" that owns these window
controllers (in document apps that's often the document, but in
your case it could also be a class of your own, or your application
delegate, or a helper object your app delegate talks to, or
whatever makes sense and keeps your source files at a manageable
size).
I'll give that a try too, once I figure out the window controllers.
Thanks.
_______________________________________________
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