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

FROM : Mike Ferris
DATE : Tue Dec 31 19:59:35 2002

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.