Utiliser pleinement le navigateur et les nouveaux clients web - AFUP 2007

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 ?

Utiliser pleinement le navigateur et les nouveaux clients web - AFUP 2007

by Eric D. on Nov 18, 2010

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 3

Statistics

Utiliser pleinement le navigateur et les nouveaux clients web - AFUP 2007 Presentation Transcript