Got it! Thanks guys for all your suggestions! On Jan 19, 2010, at 2:51 AM, Kai Brüning wrote:
> > On 18.1.2010, at 23:17, Jarod Wen wrote: > >> Good points guys! In my application the table data depends on the movie it >> comes from. And also, there will be several tables for one movie (for >> example, one is for the video information and the other is about the audio >> information). >> >> The reason why I want to select the document architecture is because all the >> table data can be edited by the user, and finally, these data should be able >> to save onto the disk as text for further usage. Maybe a wrapped file for >> both the movie and the tables will be a better choice? In this way I think a >> NSDocument for the movie and then a list of table controllers will be better? > > I’d say you are starting to approach it from the right side now: consider how > your application should be structured document-wise as the user sees it. > After you got a clear picture, mapping this to AppKit concepts is the second > step. Concerning NSDocument, this is very much tied to what the user sees as > a document: something visible in the Finder which can be double-clicked, > edited, saved again and so on. > > So you’ll have to decide whether your tables are documents in their own right > or whether the "save onto the disk as text for further usage" is an export. > In the later case you would have a single document which is able to export > tables as text files (or Excel or Numbers or HTML, you name it). > > Hope this helps a little > Kai > > >> >> Thanks! >> >> On Jan 18, 2010, at 1:59 PM, Jeffrey Oleander wrote: >> >>>> At Mon, 2010/01/18 15:19, Quincey Morris <[email protected]> >>>> wrote: >>>> On 2010 Jan 18, at 10:48, Jarod Wen wrote: >>>>> Is it a proper design to use a NSDocument as a >>>>> variable of another NSDocument? >>>>> >>>>> I am now working on an application which generates >>>>> some information from a movie. The information >>>>> generated will be showed as a table, and the >>>>> information in the table can be saved/opened. >>>>> Multiple types of information are possible >>>>> so for one movie there may be several tables. >>>>> >>>>> I used the NSDocument architecture for the movie >>>>> document, and I am a little bit confused about >>>>> the hierarchy... >>> >>>> The question isn't whether one document object >>>> can contain a reference to another document >>>> object. The question is what's supposed to >>>> happen later when the derived (table) >>>> document is re-opened. >>>> >>>> If the table refers to information in the >>>> original (movie) document, you'll need to >>>> open the movie document too. >>> >>> That depends on what you mean by "refers to". >>> >>> I can refer to the Encyclopedia Brittanica >>> without opening it. I can say "this is >>> related to the movie 'Blah' whose screen- >>> play was written by Blurp, was direced >>> by Blorp, and produced by Bloop" without >>> having to open up that movie file. >>> >>> It just depends on what Jarod Wen wants >>> to do. >>> >>> If he wants the extracted data which he >>> displays in tables to be mostly independent >>> of the original movie, then he will need >>> that to be in a document with its own >>> hierarchy. The original movie would be >>> one document with its own data, >>> and the extracted data for that movie might >>> be a separate document with its own, >>> independent data hierarchy. If he does >>> that, then the 2 files can diverge, and >>> he might have to consider how to control >>> proliferation of related data files, >>> each derived from the same movie file. >>> >>> So, his question becomes, what object >>> owns each document type? What object >>> owns the movie? What object owns the >>> derived data that he displays as tables? >>> Or, should he just keep only the movie >>> document and extract/generate at run- >>> time the data to display in table views >>> as "views of the movie". >>> >>> >>> >>> _______________________________________________ >>> >>> Cocoa-dev mailing list ([email protected]) >>> >>> 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/jarodwen%40gmail.com >>> >>> This email sent to [email protected] >> >> ------ >> J.W. >> >> >> >> >> _______________________________________________ >> >> Cocoa-dev mailing list ([email protected]) >> >> 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/lists%40kai-bruening.de >> >> This email sent to [email protected] > ------ J.W. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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]
