• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Guidance on Project Structure
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guidance on Project Structure


  • Subject: Re: Guidance on Project Structure
  • From: Donald Brown <email@hidden>
  • Date: Mon, 17 Jun 2002 05:34:39 -0500

I'm reasonably new too, but having gone through two major projects, here's
my two cents.

on 6/17/02 5:10 AM, Jeremy Dronfield at email@hidden wrote:

> 1. What factors determine the choice of document-based or
> non-document-based templates?

For me, it's the question of "Will the user want to have more than one of
these open at a time?" Calculator, control panel, sherlock, these naturally
have one window, so they aren't document based.

> 2. What factors influence the decision to add extra nibs to a project?
> (I've looked at OmniWeb's package contents, for instance, and there are
> no fewer than NINETEEN nib files in there.) And what methods can be used
> to make them communicate with each other?

First, if a window is to be shared between multiple documents, it must be in
its own nib. In my project, I've got a window with the ReadMe file, a Find
panel, and a preferences window. Each has its own nib file, with a
subclassed NSWindowController as the owner. Each window controller is
shared, so I have a factory function, +sharedWindow, that uses a static
variable to determine if the windowcontroller has been created yet, creates
if necessary, and returns the static variable.

Second, I've found it useful to encapsulate big complex parts of the
project. I've got a Layout Editor nib.

Communication is done through the sharedWindow function, and through
Notifications. The windows (where necessary) are observers for the
NSWindowDidBecomeMainNotification notification (so they always know which
document is in front), and my documents are observers of some custom
notifications to know when preferences change.

> 3. Similarly, the use of NSObject, NSWindowController (and other)
> subclasses. Vermont Recipes has helped me understand how these can be
> arranged and used, but I feel I'm missing a whole world of options to
> suit different needs.

I've only used NSWindowController for those windows that I have in separate
nibs. I've used NSObject to run some sheets, as well as for my model
classes--I have an NSObject subclass that represents the individual records
in the file, an NSObject subclass that maintains the list of records and
other bits of data associated with the NSDocument.

Donald

--
Donald Brown
email@hidden
http://www.eamontales.com

We have met the enemy and he is us - Pogo
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Guidance on Project Structure
      • From: Charles Jolley <email@hidden>
References: 
 >Guidance on Project Structure (From: Jeremy Dronfield <email@hidden>)

  • Prev by Date: Guidance on Project Structure
  • Next by Date: sending e-mails by program
  • Previous by thread: Guidance on Project Structure
  • Next by thread: Re: Guidance on Project Structure
  • Index(es):
    • Date
    • Thread