Mot-clé - laravel

Fil des billets

lundi, 6 juin 2016

Laravel : utilisation (cas d’une page dynamique)

Route

Créons une route qui mènera à la page power (c'est-à-dire http://localhost/monprojet/public/power), et dont les opérations seront gérées par la méthode activate() de mon contrôleur TestController :


Route::get('power','TestController@activate');

 

Vues

Afin d'aller un peu plus loin dans la découverte de Blade, nous allons garder les vues default.blade.php et informations.blade.php, comme nous les avons créées précédemment, mais en y ajoutant un peu de contenu.

vues.png

1. Le gabarit default (vue générique / parent)

J'ai étendu le gabarit pour permettre de constater que @yield peut agréger autre chose que des sections nommées content :


<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Page de test</title>
</head>
<body>
<h1>Mon site test</h1>

@yield('header')
@yield('nav')
@yield('content')

</body>
</html>

Nous allons voir que les @yield('header') et @yield('nav') permettent d'agréger les sections nommées 'header' et 'nav' de la vue enfant, comme cela était le cas pour la section content.

2. La vue informations (vue spécifique / enfant)

Dans la page informations.blade.php sous mon dossier test, j'ai adapté le code pour quelque chose de plus complet, qui permette de jauger plus significativement le potentiel de Blade :


@extends('default')


@section('header')
    <form method="get">
        <input type="submit" name="etat" value="{{ $value }}">
    </form>
@endsection


@section('nav')
    <ul>
        @foreach($nav as $item)
            <li><a href="#">{{ $item }}</a></li>
        @endforeach
    </ul>
@endsection


@section('content')
@if($value !== 'Activer')
    @include('test.bonjour')
@endif
@endsection

Section "header"

Dans la section header, je crée un simple formulaire en méthode GET. Aucun changement n'est observable dans cette partie du code, à l'exception de la value du formulaire qui accueille une variable entre double accolades. Les double accolades permettent d'afficher le contenu d'une variable en l'échappant. {{ $value }} revient à écrire : <?php echo htmlentities($value); ?> Le contenu de cette variable n'est pas renseigné dans la vue puisqu'il est envoyé depuis le contrôleur – que nous créerons dans le point suivant – vers la vue.

Section "nav"

Dans la section nav, j'appelle un tableau envoyé par le contrôleur – voir plus loin – sur lequel je réalise une boucle foreach et affiche chaque élément du tableau en l'échappant : {{ }}. Bien sûr, le code est adapté à la sauce Blade, tant pour l'affichage du contenu des variables que pour la boucle itérative. S'il était produit en PHP, le script serait écrit comme ceci :


<ul>
   <?php
   foreach($nav as $item) {
   ?>
     <li><a href="#"><?php echo htmlentities($item); ?></a></li>
   <?php
   }
   ?>
</ul>

Le code est donc largement simplifié puisqu'il permet notamment de se passer des (rébarbatives) balises PHP.

Section "content"

Afin d'avoir fait un tour satisfaisant des options de Blade, j'ai créé dans la section content une condition spécifiant que si la variable $value (du header) est différente d' "Activer", j'inclus une autre page nommée bonjour.blade.php, située au même niveau que la présente vue, sous le dossier test. Le @if et le @include sont également propres à la syntaxe de Blade.

3. La vue bonjour : inclusion

Voici la vue bonjour.blade.php, qui sera embarquée quand le site sera établi comme "Activé" :


<p>Le service est activé ! Les épices, c'est bon.</p>
<hr>
<p>{{ "<strong>hibou</strong>" }}</p>
<p>{!! "<strong>hibou</strong>" !!}</p>
{{-- Un commentaire --}}

On y trouve : du contenu échappé, entre {{ }}, du contenu non échappé – qui sera donc interprété – entre {!! !!}, ainsi qu'un commentaire, entre {{-- --}}. Nous verrons ce que donne le résultat de ces trois lignes de code un peu plus bas.

Contrôleur

Comme prévu, nous voilà dans la méthode du contrôleur à laquelle menait la route.


<?php
namespace App\Http\Controllers;

use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class TestController extends Controller {

	public function activate(Request $request) {
		$nav = ['aneth', 'bergamote', 'coriandre', 'estragon', 'fenouil']; ➊
		$etat = $request->etat;
		if($etat == 'Désactiver') {
			$value = 'Activer';
		} else {
			$value = 'Désactiver';
		} ➋
		return view('test.informations', compact('nav', 'value')); ➌
	}
}

➊ Nous pouvons trouver dans ce contrôleur le tableau $nav à 5 valeurs que nous avons déjà traité avec la boucle foreach (cf. point section nav de la vue 'informations').

➋ Ici, nous abordons les requêtes. Dans la ligne 11 du code ci-dessus, on affecte à la variable $etat la valeur du GET obtenue en cliquant sur le bouton (submit) du formulaire (cf. section header de la vue 'informations'). On demande en effet à Laravel d'établir une requête et d'aller chercher la valeur du GET auquel on a attribué l'attribut name, c'est-à-dire le submit lui-même.

⚠ Pour que $request->[name_du_get] fonctionne, il est nécessaire d'appeler le fichier Request au sommet du contrôleur (use Illuminate\Http\Request;) ainsi qu'en paramètre de la méthode (Request $request, Request servant à instancier l'existant). Ensuite j'établis une condition : si la variable $etat vaut "Désactiver", j'affecte à une variable nommée $value la valeur "Activer" ; mais pour toute autre valeur, la chaîne de caractères "Désactiver" sera affectée à ma variable $value.

➌ Enfin, on retourne la vue informations qui se trouve dans le dossier test, tout en passant à cette vue les variables $nav (➊) et $value (➋), de sorte qu'elles puissent y être exploitées, ce qui a été fait !

Résultat

Les vues ci-dessous varient en fonction qu'on clique sur le bouton en dessous du titre. Si l'on clique sur "Activer" (parce que le site est désactivé), on l'active, et le bouton prend alors dynamiquement la valeur "Désactiver" pour opérer dans le sens inverse (cf. Contrôleur). Par ailleurs, la vue bonjour n'est visible qu'à condition que le site soit établi comme actif (cf. Vue informations, section content).

active.png desactive.png

Conclusion

Désormais, nous avons fait un tour presque complet de Blade. @if @elseif @else, @for, @forelse, @isset – pour ne citer que celles-là – sont d'autres fonctions exploitables que vous pourrez découvrir sur la documentation officielle de Laravel. Le présent article nous a permis de voir comment communiquer des variables du contrôleur à la vue, ce qui est un premier pas vers l'élaboration d'un site ou d'une application plus dynamique. Dans le prochain article, nous verrons la gestion des formulaires en POST, Artisan (l'interface en ligne de commande) et les interactions avec une base de données. See you soon :) !

dimanche, 5 juin 2016

Laravel : utilisation (cas d'une page statique)

Vues

1. Le gabarit (vue générique / parent)

Avec Blade – le moteur de templates de Laravel –, il convient de créer un gabarit sous resources > views. Nommons le default.blade.php, et déposons-y ce contenu :


<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Page de test</title>
</head>
<body>

<h1>Mon site test</h1>

@yield('content')

</body>
</html>

Comme nous pouvons le voir, ce fichier HTML n'est pas complètement normé/standard. L'élément @yield('content') est en effet une des premières caractéristiques de Blade. L'élément yield permet d'agréger le contenu 'content' d'une page tierce, qui héritera du gabarit default.blade.php. Créons donc cette page tierce pour y voir plus clair.  

2. La vue (vue spécifique / enfant)

Dans le dossier views, créons un dossier test et créons-y un fichier informations.blade.php comprenant ce contenu :


@extends('default')

@section('content')
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
@endsection

Dans ce fichier, nous pouvons comprendre le code comme suit : hérite du fichier default (sous-entendu default.blade.php), gabarit qui agrègera (@yield) le contenu de la section 'content'.  

Route

Comme vu dans l'article précédent, le fichier routes.php – présent dans le dossier app > Http – indique l'action à accomplir en fonction de l'URL saisie dans le navigateur. Nous allons donc établir la route comme suit :


Route::get('informations', function() {
	return view('test.informations');
});

Dans le présent exemple, Laravel récupère la vue située dans mon dossier resources > views > test > informations pour l'afficher à l'adresse http://localhost/monprojet/public/informations.   ... Mais cette formulation est un raccourci barbare. Préférons-lui :


Route::get('informations', 'TestController@index');

Cette instruction peut être traduite comme suit : pour la route menant à http://localhost/monprojet/public/informations, exécute la méthode index() du contrôleur TestController. Reste donc à créer ledit contrôleur pour que la route génère un résultat...  

Contrôleur

Dans le dossier App > Http > Controllers, créez un contrôleur TestController avec ce contenu :


<?php
namespace App\Http\Controllers;

class TestController extends Controller {

	public function index() {
		return view('test.informations');
	}

}

La méthode index() du contrôleur ici présent – à laquelle il a été fait appel dans la route ci-dessus – retourne la vue informations.blade.php issue du dossier test sous resources > views (on aurait tout aussi bien pu écrire test/informations, Laravel accepte les deux nomenclatures)  

Résultat

En se rendant sur la page : http://localhost/monprojet/public/informations, nous obtenons ce résultat :  

Conclusion

Rien ne justifie le choix d'un framework pour la réalisation d'un site statique, puisqu'il complexifie énormément les choses, comme vous pouvez le voir. Toutefois, dès lors que nous exploiterons des données dynamiquement et communiquerons avec la base de données, les procédures s'en trouveront allégées : moins de code, plus de sécurité ;) . Le prochain article s'attardera sur la création d'une page plus dynamique pour permettre d'exploiter les vues Blade, les routes et les contrôleurs un peu plus loin. Et ce sera toujours sans modèle ni base de données, pour y aller pas à pas. Enregistrer

samedi, 4 juin 2016

Laravel : introduction

laravel.pngNé en 2011, Laravel est le framework PHP à architecture MVCR dont on parle probablement le plus après Symfony depuis quelques années. Je suis partie à la rencontre de cet outil, et pour ne rien perdre des connaissances que j'en ai engrangées, je délivre dans le même temps ce mémo.


Installer Laravel

  • Installer Composer.composer.png
  • Installer Laravel : depuis l’invite de commandes, accéder au dossier www/htdocs de votre wamp/xampp et exécuter la commande suivante :
    composer create-project laravel/laravel {directory} "~5.0.0" --prefer-dist
  • Établir la connexion à la base de données : adapter les paramètres sous le fichier .env à la racine du dossier.

Préambule

Arborescence du framework

  • app (cœur de votre application)
    • Commands
    • Console
    • Events
    • Handlers
    • Commands
    • Events
    • Http
      • Controllers
      • Middleware
      • Requests
    • Providers
    • Services
  • bootstrap (fichiers d’initialisation de Laravel)
  • config (fichiers de configuration)
  • database (fichiers liés à la base de données)
    • migrations
    • seeds
  • public (assets : fichiers images, js, css)
    • package
  • resources (vues et fichiers de langue)
    • lang
    • views
  • storage (données temporaires de l’application : clés de session, caches…)
    • cache
    • logs
    • meta
    • sessions
    • views
    • work
  • tests (fichiers de tests unitaires)
  • vendor (composants de Laravel & dépendances)

Routes

Laravel impose l'utilisation de routes pour faire le pont entre ses vues et ses contrôleurs. S'il s'agit d'une caractéristique plutôt rébarbative au premier abord ((Face à des frameworks comme CodeIgniter, CakePHP ou Nette qui gèrent les routes automatiquement, Laravel force à se concentrer sur une composante de plus.)), on lui reconnaît les qualités de renforcer la sécurité et surtout d'améliorer la vitesse d'affichage, et donc l'expérience utilisateur. Présent dans le dossier app > Http, le fichier routes.php indique l'action à accomplir en fonction de l'URL saisie dans le navigateur. En fonction de l'URL explorée, les routes transmettent des données à la méthode d'un contrôleur, qui se charge d'exécuter une série d'instructions – en passant si nécessaire par le modèle, destiné à l'élaboration de requêtes dans la base de données – pour renvoyer enfin le résultat à la vue.

mcvr-1.png

Artisan

Laravel propose une interface en ligne de commande nommée Artisan. Artisan permet d'automatiser toute une série d'opérations de gestion au sein du framework, telles que la création de contrôleurs, de modèles, de migrations, ou l'affichage des routes existantes établies au sein de l'application créée.

Blade

Blade est le moteur de templates dépendant de Laravel. Il fonctionne sur un système d'héritage qui lui permet d'agréger des vues, et de faciliter par ailleurs l'affichage de variables (code PHP) en échappant la plupart des données qui sont embarquées dans les vues.

Eloquent

Eloquent est un ORM (Object-relational Mapping) implémentant ActiveRecord qui permet de faciliter les requêtes dans la base de données par une syntaxe voulue plus éloquente que du simple SQL. Il supporte nativement plusieurs SGBD : MySQL, PostgreSQL, Sqlite3 et SQLServer. Eloquent est typiquement utilisé dans les modèles, situés dans le dossier app > Http. Depuis Laravel 4, il n'est toutefois plus obligatoire pour gérer les requêtes au sein du framework. Il peut être par ailleurs remplacé par d'autres ORM qui correspondraient mieux aux attentes du développeur.

Conventions de nommage

  • Les tables des bases de données doivent figurer au pluriel.
  • Les colonnes de la base de données doivent normalement figurer en snake_case.
  • Les noms de classes doivent être déclarées UpperCamelCase.
  • Le nom des méthodes et des fonctions est prévu en lowerCamelCase.
  • Les constantes sont toutes déclarées en UPPERCASE_AVEC_UNDERSCORES.
  • Le nom des modèles, rappelant celui des tables doit figurer au singulier.
  • Les contrôleurs n'imposent rien quant au genre (singulier ou pluriel).

Précautions

Contrairement à d'autres frameworks, Laravel propose une upgrade (et non une update !) à chaque sous version, et ce, de manière extrêmement rapide ((Laravel a proposé sa version 5.0 en février 2015, sa version 5.1 en juin 2015 et sa version 5.2 en décembre 2015 !)). En procédant à l'upgrade d'un projet sur lequel vous avez déjà bien avancé, vous risqueriez de ne plus pouvoir exécuter celui-ci comme avant en raison des changements opérés au sein du noyau même de l'outil en passant, par exemple, de la version 5.1 à la version 5.2 du framework. Je vous recommande donc de conserver la version avec laquelle vous avez entamé votre site/application. Toutefois, pas de panique : les différentes versions du framework sont supposées être maintenues assez durablement, et leurs documentations rester disponibles tant que les versions précédentes "vivront".

laravel-releases.png

Dans l'article suivant, nous nous pencherons sur une utilisation basique du framework – sans base de données – pour appréhender les interactions entre les routes, les contrôleurs et les vues Blade. Enregistrer

dimanche, 13 octobre 2013

Frameworks PHP : comparaison

* Liste non exhaustive

Symfonysymfony.png

Zend Frameworkzend.png

CakePHPcakephp

CodeIgnitercodeigniter.png

Yiiyii.png

Laravellaravel.png

Kohanakohana.png

FuelPHPfuelphp.png

Comparatifs