Travailler avec plusieurs modèles

En règle générale, un site comporte plusieurs modèles distincts utilisés sur toutes les pages. La page d’accueil, par exemple, aura probablement une mise en page différente de celle de la page «À propos de nous» ou d’une galerie d’images. Dans ce tutoriel, nous introduirons un modèle personnalisé pour la page d’accueil et commencerons à nettoyer un peu notre projet. en tirant parti des sous-modèles et des inclus.

Dépôt de code à télécharger

 

Créer un nouveau type de page

Créons notre deuxième modèle, basé sur celui home.htmlfourni dans le __assets/répertoire pour cette leçon. Afin de créer un nouveau type de page, nous devons d’abord ajouter une classe PHP pour le représenter. Avoir une nouvelle classe nous donnera la possibilité de créer ce type de page dans le CMS. Comme cela concerne le code, nous allons laisser le dossier du thème pour le moment et ajouter le fichier au répertoire du projet app/.

Créez deux fichiers dans votre app/srcdossier: HomePage.phpet HomePageController.php. Ajoutez le contenu suivant:

app / src / HomePage.php

 

namespace SilverStripe\Lessons;

use Page;    

class HomePage extends Page 
{

}

 

app / src / HomePageController.php

namespace SilverStripe\Lessons;

use PageController;    

class HomePageController extends PageController 
{

}

 

Nous avons choisi SilverStripe\Lessonscomme espace de noms. N’hésitez pas à utiliser ce que vous préférez. Les deux classes sont délibérément vides, car ce ne sont que des espaces réservés pour le moment. Notez que nous sous la Pageclasse afin que nous puissions hériter toutes ses propriétés et fonctionnalités, telles que $Title$Content,$Menu , etc. Cette première classe est appelée le modèle . Il contiendra tous les champs de base de données personnalisés, les relations de données et les fonctionnalités pouvant être exprimés à travers plusieurs modèles.

Par convention, chaque type de page est associé à un contrôleur qui suit le modèle de nommage [PageType] Controller. Si vous ne souhaitez pas adhérer à cette convention, définissez simplement une getControllerName()méthode dans votre modèle. Le contrôleur est la liaison entre la requête HTTP et le modèle finalisé. Les contrôleurs peuvent devenir très denses en fonctionnalités et incluent généralement des fonctions permettant d’interroger la base de données, de gérer les soumissions de formulaires, de vérifier l’authentification et de gérer tout ce qui concerne le cycle de demande / réponse.

Maintenant que nous avons ce nouveau type de page, il est nécessaire de reconstruire la base de données pour que le CMS connaisse son existence. Accédez à l’URL /dev/buildsur votre site web. Une fois le script terminé, vous devriez voir un texte en bleu indiquant que le champ a SiteTree.ClassNameété mis à jour pour être inclus SilverStripe\Lessons\HomePage.

Entrons dans le CMS à l’URL /admin, connectons-nous si nécessaire et modifions la page d’ accueil . Sous l’ onglet Paramètres , changez le type de page en page d’ accueil . Enregistrer et publier.

Quittez le CMS et rechargez la page d’accueil dans votre navigateur. Vous devriez voir le type de page par défaut avec le contenu de la page d’accueil.

 

Utilisation de la variable $ Layout

Selon les meilleures pratiques, nous ne voulons jamais coder de manière répétitive les valeurs de notre modèle susceptibles de changer. Ce principe est plus communément appelé DRY(Don’t Repeat Yourself). Un problème criant que vous avez peut-être remarqué est que, lorsque nous ajoutons de nouveaux types de page, nous devrons copier beaucoup de contenu (par exemple, la tête, la navigation et le pied de page) sur chaque page, mais avec peu de variation, l’ensemble de nos les modèles vont partager ce contenu. Ce type de contenu externe est souvent appelé le “chrome” ou votre site. Pour éviter la redondance de chrome dans chaque modèle, SilverStripe offre modèle mises en page .

Pour illustrer comment cela fonctionne, trouvons d’abord tout le contenu qui ne sera pas commun à notre page par défaut et à notre page d’accueil. Un rapide coup d’œil dans les maquettes révèle que tout ce qui se situe entre la </header>balise de fermeture et la <footer>balise d’ ouverture est un contenu unique.

Mettez en surbrillance tout le contenu entre </header>et <footer>et coupez-le dans votre presse-papiers. Remplacez tout ce contenu par la variable $ Layout .

Créez un nouveau modèle dans templates/Layoutappelé Page.ss. Collez le contenu de votre presse-papiers dans ce fichier, puis enregistrez.

De même, nous devrons créer un nouveau Layout/modèle pour notre HomePageclasse. Contrairement à Pagecela, notre HomePagetype de page est namespaced. Nous aurons besoin de créer le chemin approprié dans notretemplates/ répertoire pour le nom complet.

Faire un répertoire appelé templates/SilverStripe/Lessons. Dans ce répertoire, créez un autre répertoire appelé Layout/. Dans ce répertoire, créez HomePage.ss. Le chemin complet devrait être templates/SilverStripe/Lessons/Layout/HomePage.ss.

Maintenant, copiez le contenu entre </header>et <footer>dans le __assets/home.htmlfichier dans votre presse-papiers et collez-le dans ce nouveau fichier.

Chaque fois que nous créons un nouveau modèle, nous devons vider le cache, ajoutez donc ?flushà l’URL et rechargez. Vous devriez maintenant voir un design distinct pour la page d’accueil par rapport aux deux autres pages.

Cela peut sembler anodin, mais vous venez d’obtenir des gains énormes d’efficacité et d’organisation du code. Voici comment ça fonctionne:

  • SilverStripe voit que vous demandez une URL pour une page utilisant le HomePage.ssmodèle
  • Il commence par regarder dans le templates/répertoire principal pour trouver le chrome pour cette page. S’il trouve HomePage.ssdedans, il le sélectionnera comme votre chrome. Sinon, il passera par l’ascendance de ce type de page jusqu’à ce qu’il trouve une correspondance. Il trouve la classe parente de SilverStripe\Lessons\HomePage, qui est Page, et l’utilise.
  • La $Layoutvariable indique à SilverStripe de rechercher dans le templates/{page namespace}/Layoutrépertoire un modèle correspondant à ce type de page. Il le trouve HomePage.sset l’utilise. S’il n’avait pas trouvé HomePage.ss, il poursuivrait l’ascendance et trouverait Page.ss, et l’utiliserait comme solution de rechange.

Une grande majorité des projets SilverStripe n’ont qu’un modèle Page.ss, à la racine templates/, laissant tout le reste à{namespace}/Layout/ . Dans certaines circonstances, vous pouvez avoir un type de page dont le design est si distinct qu’il nécessite son propre chrome. Un exemple courant de ceci est une page de connexion, où l’utilisateur est présenté avec un formulaire isolé très simplifié.

 

Injection d’actifs via le contrôleur

À l’heure actuelle, nous avons toutes les dépendances CSS et Javascript codées en dur dans le modèle. Cela fonctionne bien, mais vous aurez souvent avantage à confier la gestion des dépendances au contrôleur. Cela vous permet d’exiger des fichiers spécifiques pour certaines pages uniquement, ainsi que d’inclure ou d’exclure de manière conditionnelle des fichiers en fonction d’une logique métier arbitraire.

Pour inclure ces dépendances, nous allons appeler la Requirementsclasse dans notre contrôleur. Ces dépendances étant communes à toutes les pages, nous pouvons l’ajouter PageControllerdansPageController.php .

Effectuez la mise à jour suivante de la init()méthode.

 

use SilverStripe\View\Requirements;

// ...

protected function init()
{
  parent::init();
    Requirements::css('css/bootstrap.min.css');
        Requirements::css('css/style.css');
        Requirements::javascript('javascript/common/modernizr.js');
        Requirements::javascript('javascript/common/jquery-1.11.1.min.js');
        Requirements::javascript('javascript/common/bootstrap.min.js');
        Requirements::javascript('javascript/common/bootstrap-datepicker.js');
        Requirements::javascript('javascript/common/chosen.min.js');
        Requirements::javascript('javascript/common/bootstrap-checkbox.js');
        Requirements::javascript('javascript/common/nice-scroll.js');
        Requirements::javascript('javascript/common/jquery-browser.js');
        Requirements::javascript('javascript/scripts.js');
}

Nous utilisons themedCSSet themedJavascriptlocalisons automatiquement la ressource en fonction du thème actuel. De cette façon, si le thème change, nous n’avons pas à mettre à jour le chemin.

Les seules ressources que nous n’avons pas incluses sont le fichier html5 shim inclus conditionnellement pour IE8 et la police Google chargée à partir d’un chemin absolu.

Ensuite, supprimez toutes les <script>balises et les feuilles de style de votre templates/Page.ssfichier qui sont maintenant chargées via Requirements.

 

Rangement avec comprend

Pour que nos modèles soient moins denses et plus faciles à travailler, nous allons en extraire des parties dans le templates/Includesrépertoire. Commencez par couper le <div id="top-bar" />dans votre presse-papiers. Remplacez cette div en entier par <% include TopBar %>. La déclaration d’inclusion indique à SilverStripe de rechercher dans letemplates/Includesrépertoire un modèle portant le nom que vous avez spécifié.

Créez un fichier nommé TopBar.ssdans templates/Includeset collez le contenu de votre presse-papiers. Dans ce cas, nous n’avons pas besoin d’un chemin d’espacement de noms, car le Page.ssmodèle n’est pas lui-même.

Répétez cette procédure pour <div id="nav-section" />et appelez le modèle MainNav.ss.

Répétez le processus une fois de plus pour la <footer />balise entière et appelez le modèle Footer.ss.

Enfin, supprimez tous les commentaires HTML de votre page.ss, car le modèle est maintenant trop clairsemé pour nécessiter de tels guides.

TOUT VOIR Ajouter une remarque
VOUS
Ajoutez votre commentaire
 
© Academy EdTech. 2019 All rights reserved.
X