Re: Looking for suggestions/help on a multi-file data model

I don't really see the problem. As you say, the Cocoa document model assumes one file for one document. However, isn't that what you also have? Catalogs are one file, and one document. And orders are also one file and one document. So I don't see why they can't both be one document. There can be more than one *types* of documents.

The thing is to somehow associate orders and catalogs. That can be handled on top of the document model, but I don't see why it needs to replace it. Also, I'd say that then there should also be some kind of connection in the data (the order files). And then there's the "one catalog" requirement. Now this is something you can also implement e.g. in the document controller.

However, I don't see how you are thinking about the user, because that makes no sense to me as you described it. When you have multiple catalog files on your system, what tells the user that you could have only one open? And when there's several catalog files and a lot of order files, how does the user know what is associated to what? And when they're opened, how does the user associate one with the other? So from the user perspective, I don't see how you want to organize your model and your UI. That makes it hard to associate a model to it. I think when you figure out the user model better, you may also know better how to implement it. Maybe you already know, but then you did not tell us. 

Christiaan

On Feb 12, 2011, at 3:12, Andy Akins wrote:

> I'm working on an application that has multiple files as part of its data model, and I'm not sure on the approach I should take.
> 
> An example of what I mean:
> 
> Imagine a "purchasing" application. First, you have to open a "catalog" - a file that lists the items that are available. There might be multiple files, representing multiple stores or sets of items, but you have to pick just one.
> 
> Then, you have your "order" - you select items from the opened "catalog", and have a new document that contains not only the items you are going to order, but also other information (address, name, etc).
> 
> The catalogs are separate files, and there would be either a separate app or a part of this app to edit a catalog: to add, remove, change items in it.
> 
> But orders are also separate files, that can be saved, edited, printed, etc.
> 
> I've used Core Data and the Document architecture for more simple data models, but I'm not sure if I can shoehorn this into them. I've looked at several tutorials, guides, and even read some books - but they all seem to be the One Document = One File approach. And what I want to do really doesn't fit that.
> 
> Note: The above is just a conceptual example - I'm not really writing a purchasing/catalog system. It was just what I thought of to describe my problem :) The actual product I'm working on is a bit more niche oriented, but the use case of the data involved follows the same concept: the "prime" document (order) is built/constructed using data from a defining document/template (catalog).
> 
> Can anyone point me in a direction to do some more research and/or offer some insight that might help me decide if I can use Core Data and/or Document Architecture, of if I have to go old school and roll my own? Heck, perhaps I can use CD/DA for the primary document, and have the template/definition document be something else.
> 
> I hope this wasn't too obscure - I'm not looking for a concrete solution. Instead, hoping for a little guidance/ideas on what I should try and/or look into.
> 
> Thanks for any insight you might have...
> 
> -- Andy Akins
> _______________________________________________
> MacOSX-dev mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/macosx-dev