NSDocument Workflow basado en proyectos

Question

¿Cuál es la mejor técnica que las personas han encontrado para manejar una relación proyecto/padre-hijo al usar la arquitectura NSDocument?

Mi objetivo es que un NSDocument administre un conjunto de archivos en el sistema de archivos (un paquete no opaco, similar a los directorios del proyecto Xcode, no al paquete del proyecto) junto con la configuración. Los archivos en el sistema de archivos deben ser su propio NSDocument, pero deben poder hacer referencia al proyecto NSDocument. Idealmente, este proyecto NSDocument puede mostrar NSDocuments (secundarios) de un tipo definido (en la ventana). En resumen, quiero la interfaz de edición de Xcode.

¿Me estoy acercando a esto incorrectamente? ¿Debería solo utilizar un solo NSDocument (el "documento" de la configuración del proyecto y los archivos sin formato subyacentes en el sistema de archivos)?

Answer 1

No existe una forma integrada de definir las relaciones entre documentos. Sugeriría tener una clase de documento que use controladores de ventana personalizados para hacer la mayor parte de su trabajo. Puede tener múltiples tipos de documentos usando la misma clase para determinar qué ventana debe estar activa cuando se abre un proyecto según el archivo del proyecto seleccionado. Su clase NSDocument manejaría la comunicación entre los diferentes controladores de ventana, así como la carga/descarga de diferentes controladores de ventana según sea necesario. Cada tipo diferente de archivo en el proyecto obtendría su propia clase NSWindowController personalizada, que manejaría muchas de las tareas generalmente manejadas por el documento, como cargar/guardar archivos, deshacer la gestión, etc. Dado que el controlador de ventana viene antes del documento en la cadena de respuesta, no tendría que preocuparse de reenviar la mayoría de estos eventos al controlador de ventana actual. Básicamente, esto es lo que pediste, pero estás usando controladores de ventana en lugar de documentos secundarios.