Re: [Reposted] Document based resource strategy
Re: [Reposted] Document based resource strategy
- Subject: Re: [Reposted] Document based resource strategy
- From: Keary Suska <email@hidden>
- Date: Tue, 25 Nov 2008 09:20:27 -0700
On Nov 24, 2008, at 4:40 PM, Carlos Eduardo Mello wrote:
I started with the document based template in Xcode, and now I want
to organize my resources in nib files. Here is a list of ideas/
questions I have about this whole plan. Please do comment and/or
help me figure out which way to go.
First off, the questions you are asking lead me to believe that you do
not quite understand the document-based application architecture. If
you haven't already, you should ready Apple's "Document-Based
Applications Overview" conceptual document: <file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/Conceptual/Documents/Documents.html
> (this is the local URL).
1. Create all my views (both canvas and item views) programmatically
and use nib files only for the document window where I can set up
buttons an other controls to be wired in IB with actions, etc.
2. Create a separate nib file for each type of view and load the
nib's as needed when a new view is required during execution. From
everything I've heard on this list and read in books and
documentation, this seems like a more Cocoa-like approach (?)
However I fail to see how I would benefit from this since the looks
of my views will be determined at runtime, pending user actions.
Their structure is really simple (just collored rectangles), but
their behavior/dimensions will vary... Also if I go this route, how
do I reach the individual nibs when it's time to load them?
I don't know whether #2 is more "Cocoa-like", as it doesn't really
have to do with Cocoa per se. IMHO, code gives you far more control
than nibs, but objects in nibs are easier to construct and require
less configuration code. The best I can recommend is to start with
code alone, and then consider nibs after the fact. Nib loading is
expensive and IMHO is a bit more cumbersome to work with from a purely
programmatic standpoint.
3. What is the correct way for an NSDocument subclass to access it's
associated window in order to add/remove views to the window's
content view? I see it contains an NSWindow instance, but I could
find no accessors. In all the examples I've tried so far, the views
were already contained in the nib file's window.
The window is owned by the window controller, although NSDocument has
a write-only accessor for its own purposes. You should access the
window through the window controller (which contrary to your expressed
belief above you must have). Have you looked at the "Sketch" sample
application?* Although not what you are doing, shows, among other
things, a document-based architecture with drawing.
4. My idea is to have my document controller declare an array of
canvas controllers, in order to hanldle each canvas view and its
contained items. My GUI needs to organize the canvas views as
trasnslucent layers of different colors on top of each other so that
the position of every loaded canvas's items can be compared. The app
would then move a view to the front when it's items need to be edited.
5. One other thing I am still confused about is when, in a document
based application, do I need to declare an instance of the
NSDocument subclass in the nib and when not to.
There is no rule about this, other than as necessitated by approach.
The "Sketch"* example, as well as the "TextEdit" example*, do not have
a nib owned by the NSDocument subclass, but "iSpend"* does. All are
document-based, but approach the issue differently. It is common in
the "basic" setup to have a nib owned by the document subclass, and is
probably the simpler approach. When you are able to compare and
contrast the implementations of the sample apps I mention, you will be
able to know fully when and why.
* Sample apps should be in /Developer/Examples/ . These I reference
are in /AppKit/ .
HTH,
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