Saving projects with multiple files

[ggcarlton]

I'm having difficulty finding documentation and examples about the best way of using ATF for tools that want to have a single project that gets saved to multiple files on disk.

One typical use-case would be a course-grained approach where a project is broken up into sub-layers or sub-levels. That allows a designer to work on one sub-layer at once.

A more fine-grained approach is a tool that saves its assets to many individual asset files, each one that can be editable or read-only depending on source control access. That style of tool might end up with many hundreds of asset files on disk for their project.

In both of these examples, you wouldn't just want to load up lots of documents in isolation. You instead want to open the master project document and have it load up the sub-files automatically. The sub-files are either explicitly referenced in the master project, or else perhaps they are just parsed from whatever is in a folder on disk.

ATF supports having multiple IDocuments, but I'm not sure how the master project document would work on that case. Does the DOM tree support having sub-nodes that are actually documents, so you can load a single project and it reads/writes out to multiple files automatically? It looks like the serialization in the examples doesn't have anything that would make that work.

Or is it better just ignore the IDocument system for this case, and have a single project IDocument with a custom Save() that walks the tree and does its own file saving/loading whenever it hits one of these "file layer" nodes?

Note there is some code in the examples to do with layers but I can't see anything to do with files, so it looks like they are purely an editor visibility grouping structure.

[abeckus]

One example is https://github.com/SonyWWS/LevelEditor Look for sub-level section in the docs.

Alan

[Ron2]

The TimelineEditor also has the concept of sub-documents and master documents; take a look at TimelineEditor's implementation of IDocumentClient.

Your implementation of IDocumentClient identifies logical documents by a Uri, but it's up to you how to back that logical documents with physical documents. You could divide the one logical documents into multiple physical documents.

The DomNode tree is decoupled from IDocuments. You could have one large DomNode tree with multiple child nodes that are adaptable to IDocuments, but I'm not sure why that would be beneficial -- do you want just one editing context (one undo/redo stack, one selection set) across all documents?

Maybe you should think of this from your user's point of view -- what does it mean to use the File -> Open command to open a document? Or to create a new document? Whatever that thing is, that should be a "logical document" which we represent as IDocument. It has a Uri, a dirty flag, a read-only flag, and a user-readable type. It can be backed my multiple physical documents. You can have multiple editors that show different views of that IDocument. Those editors can even have independent selection sets and undo/redo stacks (in general, "contexts").

--Ron

[ggcarlton]

Thanks, those two examples are very helpful. Particularly the level editor's GameObjectReference class.