Re: the best way to implement a document based app that also manages documents?

FROM : John Clayton
DATE : Wed Jan 01 23:36:15 2003

Mike,

Thanks a whole lot, this really helped me to understand the connections
between the objects and how the child documents get first crack at menu
events.  It convinces me to go ahead with using the document
architecture for the children.  It leaves me with one more question ...
how to best approach subclassing window controller.  For example, if
someone calls it's -window method, should I bother returning a window
ref? always return nil? I can't override to return a non-window object,
can I?  Minor questions, though you may have some well-thought out
answers.  Thanks!




On Tuesday, December 31, 2002, at 01:59 PM, Mike Ferris wrote:

> PB uses all the standard NSDocument stuff for both its project
> documents and for file documents.  It has many subclasses of
> NSDocument, but they boil down to two categories:  PBXProjectDocument
> and PBXFileDocument (and its subclasses).
>
> The one trick PB has is a subclass of NSWindowController which,
> instead of controlling whole windows, controls pieces of windows. 
> This subclass owns a view instead of a window.  NSWindowController is
> a subclass of NSResponder and a normal NSWindowController is the
> nextResponder of the window it controls.  PB's subclass insinuates
> itself into the responder chain as the nextResponder of the view it
> controls and its nextResponder is then the view's superview.  This
> puts it in line to get menu actions associated with the
> "sub-documents" in the all-in-one-window case in PB.  Then it
> reimplements the NSDocument action methods to forward them to its
> document (which usually happens kind of magically for the document
> associated with a whole window).
>
> So, when a file editor has focus in PB, its document winds up seeing
> menu actions and stuff first.  And when the file list has focus, the
> project document sees the actions.
>
> It sounds like PB has a looser association between projects and files
> than Tony's app has between documents and sub-documents...  In PB a
> project logically contains references to a bunch of files, but the
> files are stored as separate things on the disk.
>
> Mike
>
>
> Begin forwarded message:
>

>> From: John Clayton <<email_removed>>
>> Date: Tue Dec 31, 2002  7:20:16 AM US/Pacific
>> To: "Tony S. Wu" <<email_removed>>
>> Cc: <email_removed>
>> Subject: Re: the best way to implement a document based app that also
>> manages documents?
>>
>> Hi Tony,
>>
>> Thanks very much for your help.  This does answer one of my
>> questions:which document gets first crack at the menu actions.  I
>> will see what happens when my subdocs are in the fore. But since I am
>> not spawning new windows, but rather tabs, there are no nib files, no
>> window controller nor document controllers being created.  Will a
>> document that I create programatically without a window or window
>> controller get added to the responder chain?
>>
>> Thanks, John.
>>
>>
>> On Monday, December 30, 2002, at 11:17 PM, Tony S. Wu wrote:
>>

>>> I was troubled by the same thing recently because I wanted to apply
>>> this on my application.
>>> The approach I used is like this.
>>> For example, this is your file structure:
>>>
>>> MyDocument
>>>     SubDocument1
>>>     SubDocument2
>>>     SubDocument3
>>>
>>> I manage all the sub documents in MyDocument, collect them as a
>>> array or dictionary.
>>> But the sub document need not to be a subclass of NSDocument, all
>>> they need is conform NSCoding protocol.
>>> I have 1 nib file for each different type SubDocument.
>>> For example, suppose that SubDocument1 and SubDocument2 are
>>> different types.
>>> Then they should use different nib files:
>>>
>>> SubDocument1  -->  SD1nib
>>> SubDocument2  -->  SD2nib
>>>
>>> Now, set the file owner of the nib file to the document type.
>>> For example, SD1nib's file owner would have to be SubDocument1.
>>> Then when you need to initiate the document in your main document,
>>> initiate the appropriate sub document type and assign it as the
>>> nib's file owner.
>>> For example:
>>>
>>> mySubDocument1 = [[SubDocument1 alloc] init];
>>> BOOL successful = [NSBundle loadNibNamed: @"SD1nib" owner:
>>> mySubDocument1];
>>>
>>> I hope this helps.
>>> I am not totally sure it's the way to go.
>>> As I am still in the middle of developing my application's new
>>> release.
>>> But I've got a good feelings :D
>>> I think you don't need to worry about the menu actions.
>>> It will send request to the first responder, which won't be your
>>> NSDocument subclass if a sub document window is in the front.
>>> If you need more help, I could try to make a simple sample or
>>> something.
>>>
>>> Tony S. Wu
>>> <email_removed>
>>>
>>> "It takes a smart man to be stupid." ~Tony
>>>
>>>
>>> On Monday, December 30, 2002, at 04:48  PM, John Clayton wrote:
>>>

>>>> Hi,
>>>>
>>>> (this was cross-posted to cocoa-dev)
>>>>
>>>> This is a similar case to what we have in ProjectBuilder, a project
>>>> document that manages other documents.
>>>>
>>>> So, if I create a document based app using the ProjectBuilder set
>>>> up, I get an app capable of opening documents, etc.  I understand I
>>>> also get a document controller, a window controller and the methods
>>>> that come along with NSDocument.  If I get this correctly, The
>>>> DocumentController will handle most of the messages sent to
>>>> FirstResponder from menu items.  This works great for the parent
>>>> document.  But now I am wondering how to manage the child
>>>> documents. All the usual messages sent to FirstResponder get
>>>> intercepted first by the objects set up  in PB, so they never seem
>>>> to reach the children.  Ok, I think, then should I subclass
>>>> NSDocument for the children at all?  Should I then create my own
>>>> document controller and add it's methods to FirstResponder and wire
>>>> them from the menu items in IB?  Or, is there some way to route the
>>>> messages to the child documents such that the document controller
>>>> knows on which document to invoke the methods?  Is this simply a
>>>> matter of having the child documents be FirstResponder?
>>>>
>>>> I wonder if I'm making any sense here ... sigh.  Does anyone know
>>>> of an example of such an application where the source code is
>>>> available?  Your help is appreciated.  Thanks.
>>>>
>>>> Regards,
>>>>
>>>> John Clayton
>>>>
>>>> ----------------------------------
>>>> <email_removed>
>>>> ----------------------------------
>>>> How glorius it is to be an Exception, and how painful.
>>>>
>>>> _______________________________________________
>>>> MacOSX-dev mailing list
>>>> <email_removed>
>>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>>>
>>>>

>>>
>>>

>> Regards,
>>
>> John Clayton
>>
>> ----------------------------------
>> <email_removed>
>> ----------------------------------
>> How glorius it is to be an Exception, and how painful.
>> _______________________________________________
>> cocoa-dev mailing list | <email_removed>
>> Help/Unsubscribe/Archives:
>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>> Do not post admin requests to the list. They will be ignored.

> _______________________________________________
> cocoa-dev mailing list | <email_removed>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>
>

Regards,

John Clayton

----------------------------------
<email_removed>
----------------------------------
Ask a question, remain a fool for five minutes
Don't ask a question, remain a fool forever
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.