Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

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

on

  • 868 views

Il est possible d'aller plus loin que les applications classiques. En profitant pleinement des capacités du navigateur cet atelier vous montrera comment améliorer les performances et modulariser ...

Il est possible d'aller plus loin que les applications classiques. En profitant pleinement des capacités du navigateur cet atelier vous montrera comment améliorer les performances et modulariser l'existant. HTTP, REST et Ajax sont au menu pour une application orienté services légère, simple à modifier et avec une API partageable avec vos clients.

Statistics

Views

Total Views
868
Views on SlideShare
864
Embed Views
4

Actions

Likes
1
Downloads
3
Comments
0

2 Embeds 4

http://lanyrd.com 3
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  •  
  • 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 ?