Qui gère ?
● Le graphisme ?
● L'intégration
HTML/CSS/JS ?
● Le code applicatif ?
● Le SGBD ?
● Le contenu ?
Il manque quelque chose ....

Utiliser pleinement le navigateur
● C'est à vous de le faire (désolé)
● Mais le navigateur travaillera pour vous
HTTP, JSON, Cache, GET, Etag, 304, Ajax, PUT

Éric Daspet
http://eric.daspet.name/

Cache ?
● Simple, connu
– On évite de calculer
ce qui est déjà connu
● Quelle solution ?

Pear::
Cache_Lite
require_once('Cache/Lite/Output.php');
$opt = array(
'cacheDir' => '/tmp/',
'lifeTime' => 10
);
$cache = new Cache_Lite_Output($opt);
if (!($cache->start( $id ))) {
// Cache missed... making the page
$cache->end();
}

Pear::Cache_Lite
● Défauts ?

Pear::Cache_Lite
● Défauts ?
● Ca ne change rien pour le visiteur
– C'est le visiteur qui est important
● Quoi faire ?

Utiliser HTTP
● Dire « la page n'a pas changé depuis 2h »
● Dire « ça ne changera pas pendant 1h »
● Dire « Ce contenu là tu l'as déjà téléchargé »

La page n'a pas changé
● Requête conditionnelle
– 1er téléchargement « Last-Modified: hier 16h »
– par la suite « If-Not-Modified-Since: hier 16h »
– code de retour « 304 »
● On ne retélécharge pas
– on ne le calcule
parfois même pas

La page ne changera pas
● Date limite de consommation
– Expires: après demain 12h
– Cache-Control: max-age=300
●
● Le temps réel est-il nécessaire ?
– Je reviens souvent sur les mêmes pages
– Mais uniquement pour les liens, pas le contenu

Déjà téléchargé
● Requête conditionnelle (HTTP 1.1)
– 1er téléchargement « Etag: identifiant unique »
– par la suite « If-None-Match: identifiants en cache »
–
● Le plus souvent la date est préférable

Solution ?
● Anciennement : jpcache
– il existe probablement des choses plus récentes
● Plus simple et plus évident :
– Cache statique
– Reste à regénérer le cache statique au besoin
– Une architecture MVC claire peut aider

Attention aux sessions
● session_start = cache-control:private
– donc pas de proxy, peu de cache
● Pas de session sur les pages publiques
● Ou contrôle manuel du cache-control

Ce qu'on va faire
● Lien entre PHP et code client
● Pas vraiment de syntaxe PHP
● Pas vraiment de syntaxe HTML
On parlera surtout d'architecture

Application
● Pendant les grèves,
ma société met en place un service de bus
● C'est codé comme
d'habitude...
(vous voyez ce que je veux dire ?)

Je sais
● Plein d'erreurs
● Pb de sécurité
● Mauvais code
● Regardez le reste
– C'est pour l'exercice

Quoi en faire ?
● Nous devons
– la rendre plus sympa
– lui faire supporter la charge
– la rendre utilisable par des appli. tierces

Maintenant ...
● Vous travaillez
– Idée
– Évaluation
– Présentation
– Action
– Conclusion

Ajax
● Asynchronous
● Javascript
● and
● XML
● Rien à voir avec PHP

Ajax
● Possibilité de faire une requête HTTP en js
– sans bloquer le navigateur
– pour modifier la page ensuite
● Toujours rien à voir avec PHP

Ajax et PHP
● Ajax n'implique rien pour PHP
● Il s'agit d'une page normale
– XML, HTML, JSON, peu importe ...
● C'est même ça qui est génial : rien à changer

Ajax et Javascript
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState == 4 && xhr.status == 200) {
// Ici on place l'action à effectuer
}
}
xhr.open("GET", 'destination.php', true);
xhr.setRequestHeader('Content-Type','x-www-form-urlencoded');
xhr.send("name=value&name=value");

Pourquoi ?
● Éviter de tout recharger
– perdre les saisies
– recalculer ce qui est
déjà à l'écran
Lourd non ?

Pourquoi ?
● On télécharge des objets indépendants
– et pas des pages
● Une chose à calculer, une à afficher
– on profite à fond de notre MVC
● Une page classique réutilise nos parties Ajax
– les appels au modèle sont les mêmes
– les vues peuvent s'imbriquer
– on ajoute/supprime facilement des éléments

Cache ... encore mieux
● On ne pouvait pas envoyer en cache
– à cause de la personnalisation
● Si on télécharge des morceaux indépendants
– Eux peuvent être en cache
– Expiration, requêtes conditionnelles, etc.

Le client travaille
● En profiter pour faire travailler le client
– les données brutes sont communes (en cache)
– les personnalisations sont données à part
– Javascript recolle le tout
● Pas besoin de toucher aux pages classiques
– le javascript peut refaire le contrôleur
– le modèle fait le gros du travail

Un peu plus loin
● REST
– Interface « historique de HTTP »
– Une ressource (URI= identifiant, URL= localisation)
– Un verbe (GET, POST, PUT, DELETE)
– Des paramètres optionnels
● C'est le CRUD adapté à HTTP
– opérations très simples, à coder et à utiliser
– tout utilisable en Ajax

Préloading
● Devancez l'utilisateur
– Avec Ajax c'est un
vrai plaisir

Utilisez le client
● Restez un maximum statique
● Faites la personnalisation en javascript
● Vous « dégraderez » correctement
C'est pareil dans la vie réelle

Utilisez le client
● Et pourquoi pas
● directement du XSLT ?
– à réserver en interne

Encore plus
« REST »
● Auto-négociation
de contenu
– principalement pour la
langue
– car l'IP n'est pas une
bonne solution

Pour les perf
● Compression client
– tous les navigateurs le supportent

Cookies
● Passez vous des sessions
– quand les cookies suffisent

OpenId
● Passez vous même de l'authentification

Codes de retour HTTP
● 410, 403, 401, 301, 304, 204 .... quid ?