javascript - Renderizar diseños con Backbone.js

Question

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?

• 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 diferentes vistas representadas en sus columnas que aprovechan todo el modelo / vista de Backbone.js.

El problema

Cuando el usuario solicita una ruta asignada a ControllerB, todo el diseño de la página debe cambiar para no utilizar el diseño de 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

¿Utilizaría una vista de Backbone.js para representar el diseño y luego representar cada columna con sus vistas vinculadas al modelo?

Mi segundo pensamiento

¿Agregaría un método de configuración / diseño a su controlador que utilizó jQuery para representar el diseño y luego permitir que la acción responsable de la ruta lo haga? 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 para 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!

Answer 1

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.

• Crea appController, el controlador singleton para la aplicación.
• El appController crea la vista principal, esta es la vista responsable de representar el esqueleto de la página y manejar 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 cantidad de childViews para las 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 ()

Todos los módulosControladores tienen acceso a la aplicación Controlador 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 ContentView. Pueden configurar sus propios sistemas de enrutamiento complejos, usar sus propios modelos y vistas de contenido personalizadas (aunque planeamos tener una biblioteca de listViews, ObjectViews, etc. para heredar).

Estamos en la fase de diseño en este momento, por lo que realmente no puedo garantizar que este sea el diseño que finalmente utilizaremos o que no encontremos ningún agujero en él, pero conceptualmente, creemos que es sólido. ¿Comentarios?

Answer 2

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 columna individual e inyecta la vista en ese único div.

Luego, una vez que se haya registrado correctamente, de alguna manera se renderizará otro diseño (digamos una zona HEADER, zona FOOTER, zona IZQUIERDA y luego la zona MAIN (columna derecha) para todo lo demás.

El encabezado puede contener una vista de LOGOTIPO (si tiene funcionalidad) y una vista de MENÚ GLOBAL / USUARIO. La zona IZQUIERDA contendrá la vista NAV PRIMARIA.

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

No quiero que los controladores / vistas regulares se preocupen por el diseño que se está renderizando actualmente, solo que su elemento contenedor existe y está listo para ser inyectado.

Pensé en usar rutas (no en el sentido tradicional) de una manera inteligente algo así 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 fuera "/ section1 / whatever / sub / page / within / section / 1" los dos correlacionadores de ruta arriba de "regex para representar cualquier cosa menos sign_in" y "/ section1 / *" se ejecutarían ambos, lo que significa que el primario se representaría el diseño y luego se representaría la subsección sección1 si eso tiene sentido.

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

Es necesario que haya una buena forma de administrar los diseños y garantizar 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.

Answer 3

Prefiero tener ya el esqueleto de la aplicación en la página. 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 hacer esto. 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í).

Answer 4

Tiendo a estar de acuerdo con Julien: es bueno mantener tus diseños tan apagados como sea 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".