20-100.ch // Prog, news et autres trucs de geek...

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 14 mars 2010

Désactiver le layout et/ou la vue pour une action donnée dans le Framework Zend

Le Framework Zend est un framework MVC en PHP que j'affectionne particulièrement. Dans certains cas, il arrive que l'on veuille avec une action dans un contrôleur donné qui n'affiche rien, ou alors simplement du texte brut (des données JSON par exemple). Dans ce cas, plutôt que de créer un fichier vide pour la vue, il est plus simple de désactiver la vue (et le layout le cas échéant) pour cette action donnée, à l'aide du code suivante :

$this->_helper->layout()->disableLayout();
$this->_helper->viewRenderer->setNoRender(true);

dimanche 2 mars 2008

Encoder les headers personnalisé en JavaScript et les décoder en PHP

Dans la suite de mon post précédent, expliquant comment accéder à des headers HTTP personnalisés en PHP, j'ai rencontré le problème suivant : les headers sont bien transmis pour des données "simples", mais cela ne fonctionnait pas pour des caractères spéciaux ou accentués !

Vu que mes headers sont créés lors d'une requête AJAX, via le framework Opensocial, il faut d'abord pourvoir les "encoder", ou du moins "escaper" les caractères spéciaux, en JavaScript, et pouvoir les "décoder" du côté serveur, dans mon cas en PHP.

Pour ce faire, j'utilise la fonction JavaScript encodeURIComponent() du côté client :

var customHeaders = { "x-question-name" : nameValue, "x-question-text" : textValue };

var params = {};
params[opensocial.ContentRequestParameters.HEADERS] = customHeaders;

opensocial.makeRequest(url, createQuestionCB, params);


et la fonction PHP rawurldecode() du côté serveur !

$name = rawurldecode($_SERVER["HTTP_X_QUESTION_NAME"]);
$text = rawurldecode($_SERVER["HTTP_X_QUESTION_TEXT"]);

Comment récupérer des headers HTTP personnalisés en PHP

Lorsqu'on travaille avec des requêtes AJAX, une manière de passer des paramètres au serveur est via des headers HTTP personnalisés. De cette manière, on n'est pas limités par la taille maximale de 255 caractères pour une URL. Cependant, comment récupérer ces headers personnalisés du côté du serveur en PHP ?

Comme on s'y attend, ils sont bien dans l'objet $_SERVER, mais pas sous le nom escompté : il faut ajouter HTTP_ au nom de son header personnalisé, passer tous les caractères en majuscule et remplacer les - par des _ pour obtenir le nom sous lequel on trouvera ce header dans le tableau $_SERVER.

Ainsi, le header My-Header sera répertorié sous la clé HTTP_MY_HEADER dans le tableau $_SERVER !

mardi 3 juillet 2007

Problème avec le PATH_INFO pour Dotclear 2

Une des nombreuses fonctionnalités de Dotclear 2 est de permettre l'utilisation du PATH_INFO (au lieu de QUERY_STRING) comme méthode pour générer les liens. En pratique, cela veut dire que vous aurez des liens du type :

  • http://20-100.ch/blog/index.php/post/2007/07/02/Lancement-du-blog

au lieu de :

  • http://20-100.ch/blog/index.php?post/2007/07/02/Lancement-du-blog.

Quelle différence ? Hé bien, tout d'abord, c'est plus joli ;) ! Ensuite, il paraît que c'est mieux pour le référencement (une URL en mode QUERY_STRING verrait parfois la partie située après le ? être ignorée... à confirmer, mais c'est toujours ça de gagné !). Et pour finir, ça apporte un grand plus pour les statistiques de votre blog : en mode QUERY_STRING, toutes les requêtes sont considérées comme étant sur la même page (index.php), tandis qu'en PATH_INFO, chaque poste sera considéré comme ayant sa propre adresse ! Ce qui permet d'avoir des statistiques plus détaillées...

Toujours est-il qu'au lancement de ce blog, il m'était impossible d'utiliser ce mode ! En regardant un peu de plus près comment le PATH_INFO fonctionne, voici ce que j'ai trouvé :

  1. Le serveur web (Apache) extrait les données situées après le nom de la page (le /post/2007/07/02/Lancement-du-blog) pour les mettre dans un variable système
  2. Le script PHP récupère cette valeur via la variable $_SERVER["PATH_INFO"]

Je suis donc allé voir dans mon phpinfo(), si cette variable était bien définie, et je ne l'ai pas trouvée. A la place, une variable $_SERVER["ORIG_PATH_INFO"] contenait la valeur attendue. J'ai donc poursuivi mes investigation, pour découvrir que ce cas de figure apparaît sur les serveurs où PHP est en mode CGI (ce qui est le cas chez Wrackweb). J'ai aussi découvert ces lignes dans le fichier inc/config.php de Dotclear 2 :

// If you have PATH_INFO issue, uncomment following lines
// if (!isset($_SERVER['ORIG_PATH_INFO'])) {
//      $_SERVER['ORIG_PATH_INFO'] = '';
// }
// $_SERVER['PATH_INFO'] = $_SERVER['ORIG_PATH_INFO'];


Il suffisait donc de décommenter ces lignes pour que le PATH_INFO fonctionne...

Moralité : RTFM, comme diraient mes "amis" de la mailing-list Typo3 ;-)...

lundi 2 juillet 2007

Forcer le téléchargement d'un fichier

Il peut arriver certaines fois que l'on veuille force le navigateur à télécharger un fichier plutôt que de l'afficher directement dans la fenêtre. Pour ce faire, il suffit de spécifier des headers HTTP indiquant au navigateur ce qu'il doit faire.

Dans notre cas, les headers qui nous intéressent sont les suivants :

  • Content-Type : application/force-download (indique au navigateur que le contenu doit être téléchargé et non affiché)
  • Content-Disposition : attachment; filename="Nom de votre fichier.pdf" (indique au navigateur que la réponse comprend un attachment, et spécifie le nom de celui-ci)

Ces headers s'ajoutent généralement dans le code côté serveur. Voici comment faire en PHP :

header('Content-Type : application/force-download');
header('Content-Disposition : attachment; filename="Nom de votre fichier.pdf"');


et en C# :

protected void Page_Load(object sender, EventArgs e) {
   string fileName = "Nom de votre fichier.pdf";
   this.Response.ContentType = "application/force-download";
   this.Response.AddHeader("content-disposition", "attachment; filename=\"" + fileName + "\"");
}