2009-06-03 10 views
5

Tengo una aplicación de datos principales no basada en documentos. Hay un NSTreeController que administra una colección de objetos que se muestra en un solo NSOutlineView como una lista fuente. Son los tipos habituales de cosas: encabezados, carpetas, carpetas inteligentes, etc.NS (Array | Tree) Arquitectura del controlador para NSViewControllers múltiples

Cada uno de estos objetos contenedor tiene una colección de objetos contents. Tengo tres controladores de vista separados que muestran estos objetos de varias maneras (un NSTableView y dos vistas gráficas personalizadas, si realmente quieres saber). Pero en realidad son solo tres presentaciones diferentes de los mismos datos. Siempre deben mostrar los mismos objetos, compartir la misma selección, etc.

También estoy usando una jerarquía de NSViewController para administrar mis vistas. (Si hubiera sabido acerca de la excelente KTUIKit de Cathy Shive en ese momento, lo hubiera usado, pero mis controladores de vista son muy similares e inspirados por ella)

Tal como está ahora, tener un NSTreeController viviendo en el controlador de vista para la vista de la lista fuente. También tengo un NSArrayController en cada uno de los controladores de subvista que está vinculado al NSTreeController a través de algunos keypaths excesivamente complicados.

Por lo tanto, lo que hay que cambiar, en mi opinión, es la siguiente:

  • Los NSTreeController necesita moverse fuera del controlador de la vista de esquema.
  • Debería haber un solo NSArrayController al que se pueda vincular cada una de las vistas de contenido en lugar de tres vistas separadas. Aunque estoy menos seguro de este punto.

Lo que estoy teniendo dificultades con es averiguar donde estas cosas deben vivir. Me está costando decidir qué objetos, si es que hay alguno, son realmente "propios" de los diversos controladores. ¿Los controladores de vista padre lo poseen? ¿El controlador de ventana? Como se trata de datos de nivel de aplicación, ¿llego a considerarlos propiedad del delegado de la aplicación? (Podría imaginar una circunstancia en la que un uso podría querer abrir varias ventanas, aunque actualmente no es compatible) ¿Qué piensa la colmena de StackOverflow?

Respuesta

2

NSArrayController y NSTreeController se tratan más como objetos de visualización que como controladores reales, por lo que parece que va por buen camino. Comenzaría de la misma manera que tú, dándole a cada NSViewController su propio NSArrayController o NSTreeController según sea necesario, y configurando los enlaces entre ellos en tiempo de ejecución a través del controlador de ventana que es responsable de juntar todas las piezas.

Si cree que simplificaría las cosas, no parece que haya nada de malo en mover los objetos NSArrayController y NSTreeController al controlador de la ventana. Todavía podría configurar enlaces al representados Objeto del controlador de vista en IB, y luego crear los controladores de matriz/árbol en el código en su controlador de ventana en el momento apropiado. Solo sé cuidadoso para no complicarte demasiado aquí. Descubrí que cuando tienes muchos controles de vista en la misma ventana usando representObject para diferentes cosas, es más fácil crear propiedades separadas y tipadas para que puedas entender qué partes van a dónde.

Realmente no entiendo el beneficio de hacer que los controladores array/tree sean parte del delegado de la aplicación, pero no sé mucho sobre lo que está haciendo allí. ¿Tal vez te beneficiarías de crear tu propio objeto "controlador de datos"?

Preguntas como esta pueden ser difíciles de decidir ya que a veces no hay una respuesta "correcta", pero siempre que tenga en cuenta la simplicidad y la comprensión, estará bien. No tengas miedo de elegir un plan y seguir adelante, siempre puedes refactorizar más tarde ... Sé que ha habido momentos en los que he dedicado días a preguntas de arquitectura como esta, ¡cuando podría haber estado trabajando en algo más práctico!

+0

Gracias por su respuesta reflexiva! Siempre he considerado que los controladores de objetos también están más orientados a la vista. Esa es parte de la razón de mi indecisión aquí :-) No había pensado en usar representObject para los controladores; Me había resignado a hacer las fijaciones programáticamente. La motivación para esta pregunta es que he llegado al punto en el que tengo que refactorizar. Se está volviendo demasiado doloroso administrar toda la complejidad de tener controladores en lugares extraños. También descarté que el delegado de la aplicación sea el lugar apropiado. La ventana se siente como el lugar más lógico para ello. – Alex

Cuestiones relacionadas