2010-11-30 21 views
21

Si construyera una aplicación web de una sola página (SPWA) utilizando Backbone.js y jQuery con, por ejemplo, dos controladores que requirieran diseños de página únicos, ¿cómo representaría el ¿diseño?Diseños de representación con Backbone.js

  • ControllerA es un diseño de tres columnas.
  • ControllerB es un diseño de dos columnas.
  • La ruta predeterminada activa ControllerA.Welcome() - la representación inicial.
  • Ambos controladores tienen vistas diferentes representadas dentro de sus columnas que aprovechan todo el valor de modelo/vista de Backbone.js.

El problema

Cuando el usuario solicita una ruta asignada a ControllerB, todo el diseño de la página tiene que cambiar a no utilizar el diseño ControllerA. Esto ocultaría el diseño de ControllerA y mostraría el diseño de ControllerB o renderizaría el diseño si no estuviera ya en el DOM.

Mi primer pensamiento

¿Quieres que utilizar una vista Backbone.js para hacer el diseño, y luego, hacer que cada columna, con sus puntos de vista con destino a modelo?

Mi segundo pensamiento

¿Le añadir un método de configuración/diseño a su controlador que utiliza jQuery para hacer que el diseño y luego permitir que la acción responsable de la ruta haga su cosa? Usar jQuery dentro del controlador me parece un poco desagradable, pero quiero que el controlador sea responsable de garantizar que el diseño correcto esté visible para sus rutas.

Aquí hay un fragmento de mi segundo pensamiento:

var Controller = Backbone.Controller.extend 
({ 
    routes : 
    { 
     "" : "welcome" // default action 
    } 
    /** Constructor **/ 
    ,initialize: function(options) 
    { 
     console.log('Workspace initialized');    
    } 
    // LAYOUT 
    ,renderLayout : function() 
    { 
     console.log('Rendering Layout.'); 
     var $ = window.$; 
     var layout = require('js/layout/app/big_menu'); 
     $(layout.parent).html(layout.html); 
    } 
    // ACTIONS 
    /** Default Action **/ 
    ,welcome : function() 
    { 
     this.renderLayout(); 
     console.log('Do the whole model/view thing...'); 
    } 
}); 

Gracias

Gracias por tomarse el tiempo para responder. ¡Lo aprecio!

Respuesta

7

Prefiero tener el esqueleto de la aplicación presentada en la página ya. Así que tiene el diseño completo con los diferentes elementos en la página y crea su vista de estructura con esos elementos para que estén correctamente distribuidos.

Esto funciona bien cuando tienes un diseño único, las cosas se divierten cuando tienes múltiples. Puede poner todos los diseños en la página y ocultar las diferentes configuraciones según su lógica. Puede ver que el diseño es la vista inicial de una jerarquía. Entonces renderizas el diseño y luego cargas las vistas.

No hay una forma real de hacerlo. Hay pros y contras para cada uno. Una cosa que no haría es representar el diseño en el controlador. Puse todas las renderizaciones y html en vistas para poder manejar la lógica en el controlador y el modelo (creo que MVC aquí).

+0

¿No sería poner múltiples diseños en la página y ocultar en función de su lógica una gran cantidad de elementos innecesarios de carga en el escenario donde los elementos de diseño ocultos contienen datos obtenidos de la base de datos? – anxiety

+0

No. Aún usa plantillas, pero cárguelas en una etiqueta de script con un tipo de error (como js-template). Nunca utilizas el dom para almacenar información db. Use la misma técnica de script que para la plantilla anterior y cargue los datos como json. – Julien

18

Tiendo a estar de acuerdo con Julien: es agradable mantener sus diseños lo más apagados posible. Todo está siempre dispuesto en la página, en forma de esqueleto, al menos. Cuando es necesario mostrar el diseño o la configuración en particular, muestra sus contenidos de forma perezosa y muestra esa parte de la IU con CSS.Las clases CSS mutuamente exclusivas son útiles para esto, por ejemplo: "proyectos abiertos", "documentos abiertos", "notas abiertas".

+1

Lo que sea que Jashkenas diga, lo responderé. Después de todo, creó la maldita cosa: P – dguaraglia

+0

Cuanto más sin estado puede ser, mejor, en general, en mi opinión ... – jashkenas

+0

Para confirmar, su controlador debería aplicar la clase CSS que trae el esqueleto para el diseño A en foco y ocultar otros diseños en la página? Si este tipo de actividad es común, un enfoque orientado a aspectos sería genial o un método preHandler(). Gracias. –

1

Estoy teniendo exactamente el mismo problema, independientemente de Backbone o cualquier otro js framework/library.

Imagine que tiene una vista SIGN IN FORM que requiere un diseño de una sola columna e inyecta la vista en esa única div.

Luego, una vez firmado en éxito, de alguna manera se representa otro diseño (digamos una zona CABECERA, zona de pie de página, la zona izquierda y luego a la zona principal (columna derecha) para todo lo demás.

La cabecera puede contener un LOGO vista (si tiene funcionalidad) y una vista GLOBAL/MENÚ DE USUARIO. La zona IZQUIERDA contendrá la vista NAV PRIMARIA.

Luego, una complejidad adicional. Cada enlace dentro de la vista NAV PRIMARIA carga un nuevo subdispositivo listo para más vistas para inyectarse en.

No quiero que los controladores/vistas regulares se preocupen acerca de qué diseño se representa actualmente, solo que su elemento contenedor existe y está listo para ser inyectado.

pensé acerca del uso de rutas (no en el sentido tradicional) de una manera algo inteligente como:

function LayoutController() { 
App.addRouteMatcher("/sign_in/*", this.renderSignInLayout); // single column 
App.addRouteMatcher("regex to represent anything but sign_in", this.renderMainLayout); // header, footer, primary nav, main zone 
App.addRouteMatcher("/section1/*", this.renderSubLayoutForSection1); // puts a 1 column layout in the main zone 
App.addRouteMatcher("/section2/*", this.renderSubLayoutForSection2); // puts a 2 column layout in the main zone 
} 

Lo que significa que si la ruta era "/ section1/lo/sub/página/dentro/sección/1 "los dos correlacionadores de ruta arriba" regex para representar cualquier cosa menos sign_in "y"/section1/* "se ejecutarían, lo que significa que el diseño primario se representaría y luego se representaría el substrato de sección1 si eso tiene sentido.

Luego, todos los demás controladores normales usan rutas en el sentido tradicional.

Tiene que haber una buena forma de administrar diseños y asegurarse de que esos diseños, subdispositivos y vistas se destruyan de forma segura para garantizar que las pérdidas de memoria se manejen por otros motivos.

Me encantaría escuchar a alguien que ha diseñado e implementado algo elegante.

+0

Esta es una pregunta que vale la pena, pero debe ser en una publicación separada. –

6

Estoy diseñando un sistema de intranet basado en módulos usando backbone.js y básicamente uso el siguiente algoritmo en la carga de documentos.

  • Crear appController, el controlador singleton para la aplicación.
  • El AppControler crea la MAINVIEW, esta es la opinión encarga de representar el esqueleto de la página y el manejo de los clics de los elementos persistentes en la página (botones de inicio de sesión/cierre de sesión, etc.)
  • El MAINVIEW crea una serie de childViews para el diferentes partes de la página, navegación, rutas de navegación, encabezado, barra de herramientas, contentContainer, etc. Estos son los accesorios de la aplicación y no cambian, aunque sí lo hacen sus respectivos contenidos. El contenidoArea en particular puede contener cualquier diseño.
  • El appController se ejecuta a través de los módulos registrados, iniciando el MainModuleController para cada uno de ellos. Todos estos tienen esquemas de enrutamiento de espacios de nombres.
  • Backbone.history.start()

Los moduleControllers todos tener acceso a la AppControler en init. Al capturar una ubicación hash, envían un evento pageChange al appController que contiene un objeto pageManifest.El objeto pageManifest contiene toda la información necesaria para establecer las vistas respectivas, como la información de las migas de pan, la información del encabezado y, lo que es más importante, una referencia a un contentView instanciado. AppController utiliza la información en la páginaManifest para configurar las diferentes vistas persistentes, elimina la anterior contentView en contentContainer e inserta el contentView proporcionado por el módulo en el contenedor.

De esta manera, diferentes diseñadores pueden trabajar en diferentes módulos y todo lo que tienen que saber es la especificación del objeto pageManifest y cómo debería verse el contenido. Pueden configurar sus propios sistemas de enrutamiento complejos, usar sus propios modelos y visualizaciones de contenido personalizadas (aunque planeamos tener una biblioteca de listViews, ObjectViews, etc. para heredar).

Estamos en la fase de diseño en este momento, así que no puedo garantizar que este sea el diseño que finalmente utilizaremos o que no encontramos ningún agujero en él, pero conceptualmente, creemos que es sonido . ¿Comentarios?

+0

Enfoque muy interesante. Sería realmente agradable ver algunas muestras de código de cómo lo implementó, ya que estoy luchando con un problema similar que está resolviendo. –

+1

Estamos lanzando mañana, así que cuando las cosas se calmen, volveré con algunas muestras :) –

+1

Algunos de nosotros todavía estamos esperando :) – pws5068