Pregunta

Si se va a construir una aplicación de una sola página web (SPWA) usando Backbone.js y jQuery con - por ejemplo - dos controladores que cada uno requiere un único diseños de página, ¿cómo hacer que el diseño

  • ControllerA es un diseño de tres columnas.
  • ControllerB es un diseño de dos columnas.
  • La ruta predeterminada activa ControllerA.Welcome () -. La prestación inicial
  • Ambos controladores tienen diferentes puntos de vista prestados dentro de sus columnas que se aprovechan de todo el modelo Backbone.js / vista bondad.

El problema

Cuando el usuario solicita una ruta asignada a ControllerB, la totalidad de las necesidades de diseño de página a cambio de no utilizar el diseño ya ControllerA. Esto ocultar la disposición de ControllerA y mostrar la disposición de ControllerB -. O bien, hacer que el diseño si no está ya en el DOM

Mi primer pensamiento

¿Quieres que utilizan un Backbone.js objeto de lograr que el diseño, y luego, hacer que cada columna con sus vistas en modelos cota?

Mi segundo pensamiento

¿Le agrega 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 de hacerlo cosa? Usando jQuery dentro del controlador se siente un poco fuera de mí, pero, quiero que el controlador sea responsable de garantizar la disposición correcta es visible por sus rutas.

A continuación se muestra 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!

¿Fue útil?

Solución

Yo prefiero tener el esqueleto de la aplicación distribuida en la página ya. Por lo que tiene el diseño completo con los diferentes elementos de la página y crear su visión columna vertebral contra esos elementos por lo que se pusieron a cabo correctamente.

Esto funciona bien cuando se tiene un único diseño, las cosas se ponen divertido cuando tienes múltiples. Se puede poner todas las presentaciones en la página y ocultar las diferentes configuraciones en función de su lógica. Puede ver el diseño ha de ser el punto de vista inicial de una jerarquía. Así renderizar el diseño y luego tener la carga de puntos de vista.

No hay verdadera forma de hacer esto. Hay pros y los contras de cada uno. Una cosa que no haría es rinden el diseño en el controlador. Pongo toda prestación y HTML en las vistas para que pueda hacer frente a la lógica en el controlador y el modelo (MVC pensar aquí).

Otros consejos

Estoy de acuerdo con Julien - Es bueno para mantener los diseños a medida de lo posible sin estado. Todo está siempre colocado sobre la página, en forma de esqueleto, por lo menos. Cuando el diseño en particular o necesidades de configuración que se muestran, que perezosamente-Render su contenido, y mostrar esa parte de la interfaz de usuario con CSS. Mutuamente excluyentes clases CSS son útiles para esto, cosas como: "proyectos-abierto", "documentos abiertos", "notas-abiertas"

.

Estoy diseñando un sistema de intranet basada en módulos utilizando Backbone.js y yo, básicamente, utilizar el siguiente algoritmo de la carga del documento.

  • Crear AppControler, el controlador singleton de 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 (botón de conexión / desconexión, etc.)
  • El MAINVIEW crea una serie de childViews para las diferentes partes de la página, la navegación, el pan rallado, encabezado, barra de herramientas, contentContainer, etc. Estos son los accesorios de la aplicación y que no cambian, aunque sus respectivos contenidos hace. El contentArea en particular, puede contener cualquier diseño.
  • El AppController corre a través de los módulos registrados, iniciando la mainModuleController para cada uno de ellos. Todos ellos tienen espacios de nombres de enrutamiento esquemas.
  • Backbone.history.start ()

Los moduleControllers todos tener acceso a la AppControler en init. Cuando la captura de un hash-ubicación, envían un evento pageChange a la AppControler que contiene un objeto pageManifest. El objeto pageManifest contiene toda la información necesaria para establecer los puntos de vista respectivos, tales como información de pan rallado, la información de cabecera, y lo más importante, una referencia a un contentView instanciada. El AppController utiliza la información en el pageManifest a configurar los diferentes puntos de vista persistentes, elimina la antigua contentView en el contentContainer e inserta el contentView proporcionada por el módulo en el recipiente.

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 el contentView debe mirar. Se pueden establecer sistemas de enrutamiento complejas de su cuenta, utilizar sus propios modelos y contentViews personalizados (a pesar de que va a tener una biblioteca de listviews, objectViews, etc heredar de).

Estamos en la fase de diseño en este momento, así que no puedo garantizar que este es el diseño finalmente vamos a usar o que no encontramos ningún agujero en ella, pero conceptualmente, creemos que es de sonido. Comentarios?

Estoy teniendo el mismo problema exacto independientemente de la espina dorsal o cualquier otro marco js / biblioteca.

Imagine que tiene un letrero en la vista formulario que requiere un único diseño de columna y se inyecta en la vista que una sola div.

A continuación, 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 una vista LOGO (si tiene funcionalidad) y una vista menú global / USUARIO. La zona LEFT contendrá la vista NAV primario.

A continuación, una complejidad adicional .; Cada enlace dentro de las primarias de cargas de la vista de navegación hasta un nuevo sub Disposición del listos para nuevas vistas para inyectar a sí mismos en.

No quiero los controladores regulares / vistas a preocupan por lo que la disposición se hace en la actualidad, sólo que existe su elemento contenedor y está listo para ser inyectado en.

pensé acerca del uso de rutas (no en el sentido tradicional) de una manera inteligente algo 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 comparadores de ruta mencionados "expresiones regulares para representar cualquier cosa menos sign_in" y "/ section1 / *" haría ambos se ejecutan, significado que la disposición primaria se volvería y luego la disposición sub sección 1 se volvería después si eso tiene sentido.

A continuación, todos los demás controladores normales utilizan rutas en el sentido tradicional.

No tiene que ser una buena manera de gestionar diseños y garantizar esos diseños, diseños y sub puntos de vista son derribadas con seguridad para asegurar pérdidas de memoria se manejan entre otras razones.

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top