Thanks a lot for your reply.
(for some reason I am not receiving my own posts, so I never know if
they reached someone. Apparently yours was also the only response so
far...)
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).
Actually I have read all of it, and yes, I think I do have a decent
understanding of the document architecture and each
classes' (NSDocument, NSWindowControler, NSDocumentControler) role in
it.It's just that all this wiring in IB is very new to me. I think I
can organize my ideas better when writing code...
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.
That's how I feel about this. Guess I 'll use nibs for laying out
basic window structure and views that don't move or change, and code-
define movable objects' behavior.
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.
Maybe i didn't express myself well enough. What i meant about the
window controler was that its default behavior, as implemented in the
doumen-basedt application template, was enough for my needs (at least
for right now). Therefore I didn't antecipate needing to subclass it.
Instead, I planned on adding my views to the window and using the
NSDocument subclass as a controller for the application-specific
behavior. Maybe this is not the most pure design, Cocoa-wise, but at
least I'll be able to concentrate on my app's behaviour right away.
By the way, I solved that problem by adding a fixed background view
to the document window in the nib file and adding an outlet to it in
my document controler, which also enabled me to have a nice permanent
"back-grid" to aid in object's alignment.
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.
Guess I wasn't clear again... I'm not talking about the fact that the
NSDocument subclass owns the document window nib, as in 'iSpend'.
What I mean is this: if you check the tableview in iSpend, it has its
datasource outlet connect to a TransactionsControler object which
was instantiated in the nib itself, while its delegate outlet is
wired to the File's Owner icon. Some document based examples,
instead of connecting its interface items to the FIle's Owner icon,
instantiate an object of the document subclass in the nib and connect
to it. My question is: how do the two types of connection differ as
far as the kinds of things you can do with them?
* Sample apps should be in /Developer/Examples/ . These I reference
are in /AppKit/ .
Thanks for pointing me to these examples. I learned a lot by looking
at them. And you are right, I am not really trying to write a vector
drawing app, but there are definetly some functionality in common. My
views are just abstract visual representations of my data items.
They all have similar shapes but grow/shrink in width depending on
internal values. As oposed to Sketch, I don't need so many different
types of views and corresponding controlers (which is nice), and
that's why I opted for having only one centralizing controler for the
document. Another reason is that my data model is in a separate
framework, which although having various internal parts, only has one
entry point, a class which aligns itself nicely with the document
level. So i have a pointer to it as a member of the document
controler, acting as its main hook to the data model.
Thanks again for responding.
Carlos.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
