Layouts Rendu avec Backbone.js

Question

Si vous deviez construire une application web d'une seule page (SPWA) en utilisant Backbone.js et jQuery avec - par exemple - deux contrôleurs que chacun avait besoin d'un mise en page uniques, comment voulez-vous rendre la mise en page

• ControllerA est une mise en page à trois colonnes.
• ControllerB est une mise en page à deux colonnes.
• La route par défaut active ControllerA.Welcome () -. Le rendu initial
• Les deux contrôleurs ont des vues différentes rendus dans leurs colonnes qui tirent parti de l'ensemble du modèle Backbone.js / vue bien.

Le problème

Lorsque l'utilisateur demande une voie tracée à ControllerB, tous les besoins en mise en page pour le changement de ne plus utiliser la mise en page de ControllerA. Cela cacherait la mise en page de ControllerA et montrer la mise en page de ControllerB -. Ou rendre la mise en page, sinon déjà dans les DOM

Ma première pensée

Souhaitez-vous utiliser un Backbone.js vue de rendre la mise en page, puis, rendre chaque colonne avec ses vues-modèle lié?

Ma deuxième pensée

qu'il faudrait ajouter une méthode de configuration / mise en page à votre contrôleur utilisé jQuery pour rendre la mise en page et permettre à l'action responsable de la route faire des choses de ce? En utilisant jQuery dans le contrôleur se sent un peu hors de moi, mais je veux que le contrôleur soit chargé de veiller à la mise en page de droite est visible pour les routes est tout.

Voici un extrait pour ma seconde pensée:

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...');
    }
});

Merci

Merci d'avoir pris le temps de répondre. Je l'apprécie!

Answer 1

Je préfère avoir le squelette de la demande établie sur la page déjà. Vous avez donc la mise en page avec les différents éléments de la page et vous créez votre point de vue fédérateur contre ces éléments de sorte qu'ils sont posés correctement.

Cela fonctionne bien lorsque vous avez une mise en page simple, les choses se amusant quand vous avez plusieurs. Vous pouvez mettre toutes les dispositions sur la page et masquer les différentes configurations en fonction de votre logique. Vous pouvez voir la mise en page a la vue initiale étant d'une hiérarchie. Alors vous rendre la mise en page et ensuite la charge de vues.

Il n'y a pas de véritable une façon de le faire. Il y a des avantages et des inconvénients pour chacun. Une chose que je ne ferais pas est rendu la mise en page dans le contrôleur. Je mets tout le rendu et html dans les vues pour que je puisse faire face à la logique du contrôleur et le modèle (pensez MVC ici).

Answer 2

Je suis d'accord avec Julien - il est agréable de garder vos mises en page sans état possible. Tout est toujours mis sur la page, sous forme squelette, au moins. Lorsque la mise en page ou des besoins particuliers de configuration à afficher, vous paresseusement-render son contenu, et d'afficher la partie de l'interface utilisateur avec CSS. classes CSS SOLIDAIRE exclusives sont utiles pour cela, des choses comme: "projets ouverts", "documents ouverts", "notes-ouvertes"

.

Answer 3

Je suis la conception d'un système intranet basé sur des modules en utilisant Backbone.js et je l'utilise essentiellement l'algorithme suivant la charge du document.

• Créer AppController, le contrôleur singleton pour l'application.
• AppController crée le MainView, c'est le point de vue responsable du rendu du squelette de la page et la manipulation des clics pour les éléments persistants sur la page (boutons de connexion / déconnexion, etc.)
• Le MainView crée un certain nombre de childViews pour les différentes parties de la page, la navigation, mie de pain, en-tête, barre d'outils, contentContainer, etc. Ce sont les lieux de l'application et ils ne changent pas, bien que leur contenu respectif fait. Le contentArea en particulier peut contenir toute mise en page.
• Le AppController passe par les modules enregistrés, initiant la mainModuleController pour chacun d'eux. Ils ont tous les espaces de noms de routage des schémas.
• Backbone.history.start ()

Les moduleControllers tous les accès de gain AppController sur initialisation. Lorsque la capture un emplacement de hachage, ils envoient un événement pageChange à AppController contenant un objet pageManifest. L'objet pageManifest contient toutes les informations nécessaires pour définir les points de vue respectifs, tels que les informations de mie de pain, les informations d'en-tête, et surtout, une référence à un contentView instancié. AppController utilise les informations dans le pageManifest la configuration des différents points de vue persistants, supprime l'ancien contentView dans le contentContainer et insère le contentView fourni par le module dans le récipient.

De cette façon, les différents concepteurs peuvent travailler sur différents modules et tout ce qu'ils doivent savoir est la spécification de l'objet pageManifest et comment le contentView devrait ressembler. Ils peuvent mettre en place des systèmes de routage complexes de leur propre, utiliser leurs propres modèles et contentViews personnalisés (bien que nous prévoyons d'avoir une bibliothèque de listviews, objectViews, etc hériter de).

Nous sommes à la phase de conception en ce moment, donc je ne peux vraiment garantir que c'est la conception que nous allons enfin utiliser ou que nous ne trouvons pas de trous dans, mais sur le plan conceptuel, nous pensons qu'il est le son. Commentaires?

Answer 4

Je suis le même problème peu importe Backbone ou tout autre cadre js / bibliothèque.

Imaginez que vous avez un CONNECTER vue formulaire qui nécessite une mise en page de colonne unique et vous injectez la vue dans cette une seule div.

Ensuite, une fois signé avec succès, en quelque sorte une autre mise en page est rendu (permet de dire une zone HEADER, zone de bas de page, zone à gauche puis la zone principale (colonne de droite) pour tout le reste.

L'en-tête peut contenir une vue LOGO (si elle dispose d'une fonctionnalité) et une vue MENU GLOBAL / USER. La zone de gauche contiendra la vue principale de NAV.

Ensuite, une autre complexité .; Chaque lien dans les charges PRIMAIRES vue de NAV une nouvelle sous layout prête pour d'autres vues s'injectent dans.

Je ne veux pas que les contrôleurs réguliers / vues se soucier de ce que la mise en page est actuellement rendu, juste que leur élément conteneur existe et est prêt à être injecté dans.

Je pensais que sur l'utilisation de routes (pas dans le sens traditionnel du terme) dans un quelque chose de façon intelligente comme:

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 
}

Ce qui signifie que si la route était "/ Section1 / whatever / sous / page / dans les / section / 1" les deux matchers d'itinéraire ci-dessus "regex pour représenter quoi que ce soit, mais sign_in" et "/ Section1 / *" serait à la fois l'exécution, sens que la mise en page principale serait rendu et la mise en page Section1 sous serait rendu après si cela fait sens.

Ensuite, tous les autres contrôleurs normaux utilisent les routes dans le sens traditionnel.

Il doit être une belle façon de gérer et d'assurer les mises en page mises en page, mise en page sous et points de vue sont démolis en toute sécurité pour assurer les fuites de mémoire sont traitées entre autres raisons.

aimerais entendre quelqu'un qui a conçu et mis en œuvre quelque chose d'élégant.