Blog de la rubrique Web » PHP

HTML Media Capture : prenez des photos depuis un champ de formulaire

Bovino — Thu, 16 Jan 2014 14:29:47 +0000

HTML Media Capture et l’attribut capture.
Mettez à profit les périphériques de votre mobile pour remplir les champ file

HTML5 apporte de nombreuses nouvelles fonctionnalités, notamment concernant les formulaires.

Nous allons voir dans ce billet la spécification HTML Media Capture.
Celle-ci permet d’élargir les capacités des champs de formulaires de type file.
Jusqu’à présent, les champs de formulaires de type file permettaient juste d’ouvrir une fenêtre pour récupérer dans le système de fichiers celui (ou ceux) à envoyer avec le formulaire.
Il est dorénavant possible d’utiliser ces mêmes champs pour utiliser l’un des périphériques de capture (audio, vidéo ou image) pour créer le fichier à envoyer.

Comment le mettre en œuvre ?
La mise en place d’un tel système est particulièrement simple.
Il suffit d’ajouter au champ un attribut capture et le tour est joué ! Cet attribut étant de type booléen, c’est-à-dire que sa seule présence (sans valeur ou quelle que soit sa valeur) suffit à indiquer au navigateur le comportement souhaité.

Enfin… il suffit… pas tant que ça en fait.
En réalité, l’attribut capture n’est pas suffisant, en effet, ce seul attribut ne permet pas de savoir quel type de media est demandé, donc quel périphérique utiliser.
Il est donc nécessaire de préciser aussi l’attribut accept avec une valeur correspondant au type mime souhaité.

Notez que l’attribut capture n’oblige pas l’utilisateur à utiliser un périphérique : il lui est demandé s’il veut envoyer un fichier existant ou s’il veut utiliser le périphérique approprié.

Exemples.
Voici les trois cas possibles d’utilisation à l’heure actuelle :

Compatibilité.
À l’heure actuelle, seuls les navigateurs pour mobiles et tablettes semblent supporter cette fonctionnalité.
Voir la table de compatibilité pour mobiles.
Mais gageons que les versions desktop des navigateurs vont l’implémenter rapidement.

Voir les spécifications du W3C (comprenant des exemples plus avancés).

Forcer le chargement d’un fichier en HTML5

Bovino — Thu, 31 Oct 2013 15:37:20 +0000

Lorsque vous proposez une ressource aux visiteurs de votre site (images, documents PDF ou autres, etc.), les navigateurs vont essayer de les afficher via des fonctionnalités intégrées ou des extensions/plugins.
Or, si vous souhaitez juste proposer ces ressources au téléchargement, vous serez obligé de « forcer la main » au navigateur côté serveur :

En gros, la technique consiste à associer au fichier souhaité un en-tête HTTP Content-Disposition qui indiquera que celui-ci doit être téléchargé et non affiché.

Bien entendu, si votre page est uniquement en (X)HTML, vous êtes de la revue ! La seule technique possible est de transformer votre fichier dans un format qui ne peut être affiché par le navigateur (la technique la plus classique étant de le compresser en archive zip).

Mais cela, c’était avant.
Car désormais, HTML5 vous permet de rendre vos fichiers téléchargeables, quel que soit leur format, de façon très simple.

Il suffit d’utiliser l’attribut download.

Comment s’utilise cet attribut ?
Le plus simplement du monde : en l’intégrant à la balise <a> ou !

Quelle valeur donner à cet attribut ?
Celle que vous souhaitez.
Plus exactement, la valeur va correspondre au nom de fichier présélectionné dans la fenêtre de téléchargement, mais si vous ne précisez pas de valeur (download) ou si vous mettez une valeur vide (download=""), alors le nom de fichier par défaut sera celui du fichier original.
Exemples :

<a href="foo.png">Enregistrer</a>
<a href="foo.png">Enregistrer</a>
<a href="foo.png">Enregistrer</a>

Quels types de fichiers peuvent être téléchargés ?
Il n’y a pas de restriction sur les types de fichiers que vous pouvez proposer en téléchargement, néanmoins, ils devront respecter la Same Origin Policy (même domaine, même TLD, même sous domaine, même protocole, même port).
Notez aussi que vous pouvez proposer en téléchargement des fichiers encodés en base64, donc en particulier des fichiers générés depuis le navigateur.

Mais alors, mes codes serveur peuvent être téléchargés ?
Bien sûr que non, heureusement !
Si vous demandez un fichier .php par exemple sur le serveur, celui-ci sera d’abord interprété avant d’être envoyé. Ce sera donc le fichier généré qui sera récupéré et non le fichier contenant le code source.
Il est donc en revanche possible de proposer de télécharger des fichiers images (par exemples) générés dynamiquement sur le serveur.

Quel est le support des navigateur ?
C’est le bémol concernant cet attribut…
À l’heure actuelle, seuls Firefox, Chrome et Opera (en version desktop ou mobile) ne reconnaissent cet attribut, pour les autres navigateurs, vous devrez passer par une solution de contournement.

Comment savoir si un navigateur prend en charge download ?
Il est possible, avec JavaScript, de détecter si la fonctionnalité est supportée, pour cela, on crée un nouvel élément <a> et on vérifie s’il possède une propriété download :

var testA = document.createElement('a');
if('download' in testA){
// Le navigateur supporte l'attribut download
}
else{
// Le navigateur ne supporte pas l'attribut download
}

Voir une page d’exemple.

PHP Tour Lille 2011

Bovino — Thu, 24 Nov 2011 17:59:36 +0000

Voilà enfin arrivé ce jour tant attendu (en tout cas par moi). Je suis donc prêt, bic et carnet en main, à prendre pleins de bonnes notes sur les différents aspects de PHP.

8h30, je suis sur le parking et avance vers le site de Euratecnologies de Lille. Déjà, rien que pour la réaffectation de ce bâtiment, le détour en valait la peine.

Après avoir récupéré mon badge et mon petit cadeau, un éléphant rose (ça va se chamailler à la maison), je me dirige vers l’auditoire pour la keynote présentée par Jean-Marc Fontaine de Alter Way.
La bienvenue nous est souhaitée et la présentation des deux jours nous est narrée, tout en nous présentant l’AFUP et en nous motivant pour ouvrir des antennes dans nos régions (peut-être une bonne idée à creuser là).

Le sujet de la première conférence à laquelle j’ai assisté est la présentation de PHP 5.4 par Julien Pauli, nous expliquant les grandes nouveautés, qui ne se trouvent pas forcément dans le langage, mais bien dans sa construction, avec la mise en place de RFC, permettant à chaque utilisateur d’émettre des changements dans le langage.
Un cycle de vie déterminé de 3 ans par mise à jour majeure et de 1 an pour une mise à jour mineure.
De plus une bonne nouvelle est que la descendance ne sera plus cassée dans les versions mineures.
Bien sûr, les nouveautés liées au langage nous sont présentées, mais cela n’est plus un secret et l’on trouve tout sur developpez.com.
Par contre, Julien nous annonce un gain de performance de l’ordre de 55% par rapport à PHP5.3, avec benchmark à la clé.
Julien nous a promis ses slides sur le site de l’AFUP très prochainement.

Ensuite, j’ai assisté à l’industrialisation du site lamaisondevalerie.fr , faisant partie du groupe Conforama, présentée par Sophie Beaupuis.
Ici expliquer en quelque mots serait difficile tant les infos étaient nombreuses, on a pu voir tout le panel d’outils utilisés pour le développement de son application (très orienté Zend avec la suite de produit complets).
Ce qui était agréable dans cette présentation est que madame Beaupuis s’est mouillée en nous expliquant les freins liés à son projet et a eu l’honnêteté de dire ‘désolée je ne connais pas’.

J’ai pris 5 minutes pour vous faire ces quelques lignes et je remercie Jean Marc Fontaine de m’avoir trouvé un petit Wifi.
Ce soir je vous poste la suite de cette première journée.
Un seul regret actuellement, est de ne pas avoir pris de CV avec moi, parce que les offres d’emploi ici sont palpables… Merci le réseautage !

Par MaitrePylos

Un classique AJAX : utiliser les données au bon moment !

Bovino — Fri, 11 Nov 2011 13:46:23 +0000

S’il est une erreur classique chez les débutants en AJAX, que l’on retrouve régulièrement sur le forum AJAX, c’est de vouloir utiliser les données du serveur avant de les avoir reçues.

Faisons une petite analogie.
Imaginons que vous ayez une poule. Tous les matins, vous souhaitez savoir combien d’œufs ont été pondus, vous envoyez donc quelqu’un les compter.
J’imagine, qu’au moment même où cette personne part compter les œufs, il ne vous viendrait pas à l’esprit de l’appeler pour lui demander le compte : la moindre des choses est d’attendre qu’elle soit revenue car avant, elle ne connait pas l’information !

Avec AJAX, c’est exactement pareil. Le premier A de l’acronyme signifie asynchronous (asynchrone), c’est-à-dire que JavaScript ne va pas attendre la réponse du serveur avant de continuer à exécuter le code, sauf bien entendu si vous avez spécifié le mode synchrone.
Ainsi, le seul moment où l’on est sûr d’avoir reçu la réponse est lorsque la propriété readyState de l’objet XMLHttpRequest vaut 4 et que la propriété status correspond à un code de réussite de la requête (classiquement 200). C’est pourquoi tous les traitements se basant sur la réponse du serveur doivent être traités dans le callback de la requête..

Avant d’écrire son code, il est donc fondamental de se demander si les données que l’on veut utiliser existent ou non.

A titre d’exemple, un petit code :

var xhr = new XMLHttpRequest(), monResultat;
xhr.open('POST', url);
xhr.onreadystatechange = function(){
if(xhr.readyState == 4 && xhr.status == 200){
monResultat = xhr.responseText;
alert(monResultat);
}
};
xhr.send('variable=valeur');
alert(maVariable);

Ici, le premier alert() affiché sera celui de la dernière ligne : JavaScript n’attend pas la réponse du serveur pour continuer à exécuter le code et cette alerte affichera undefined, puisqu’au moment où cette instruction est interprétée, aucune affectation n’a encore été faite pour maVariable ! Puis, lorsque le serveur aura répondu, le second alert() sera affiché avec cette fois la valeur attendue.

Voir aussi :

Le HTML5, c’est pour quand ?

Bovino — Mon, 10 Oct 2011 20:24:29 +0000

S’il est bien une question qui revient régulièrement sur les forums Développement Web, c’est de savoir quand on pourra commencer à utiliser le HTML5.

La bonne nouvelle

La bonne nouvelle, c’est que la réponse est très simple : il est déjà possible de publier des pages en HTML5 !

Ah bon ? Tous les navigateurs sont compatibles ?

Voilà effectivement la question sous-jacente à la précédente : quelles sont les fonctionnalités apportées par HTML5 déjà exploitables en production.
A cette question, il est difficile de répondre : les choses évoluent très vite et ce qui est vrai aujourd’hui ne le sera pas demain.
D’autre part, répondre à cette question n’est pas l’objet de ce billet !
En revanche, ce qu’il faut garder à l’esprit, c’est que le HTML5 ne se limite pas, encore heureux, aux nouvelles balises et aux nouvelles interfaces.
De plus, le HTML5 est pensé pour être complètement rétro-compatible, ce qui signifie que toute page codée en HTML 4 ou en xhtml 1 valide est valide en HTML5 !
Alors il ne faut pas hésiter : vous pouvez dès à présent passer toutes vos pages en HTML5, même si elles ne comportent aucun des ajouts apportés.

D’accord, mais alors comment faire ?

C’est très simple : il suffit juste de préciser le doctype adapté. En plus, le doctype HTML5 est le plus simple qui soit :

Vous ne vous souvenez plus s’il faut l’écrire en majuscule ou en minuscule ?
Ce n’est pas grave, il est insensible à la casse !
Vous pouvez aussi aller plus loin, puisque le HTML5 prévoit une balise meta spéciale pour indiquer l’encodage :

Là encore, faut-il ou non fermer les balises selon la norme XML, comme dans cet exemple ?
Mais ici aussi, HTML5 accepte les standards HTML ou xhtml, ce qui signifie que c’est comme vous le souhaitez (essayez toutefois de rester cohérent pour l’ensemble de la page).

En conclusion, étant donné la simplification qu’apporte le HTML5 en ce qui concerne de doctype, il serait dommage de s’en priver : essayez et validez vos pages sur le site du W3C, vous comprendrez que le HTML5, c’est pour hier !

Adobe annonce l’ouverture du protocole RTMP

freegreg — Wed, 21 Jan 2009 19:10:40 +0000

Depuis longtemps réclamé par la communauté, Adobe annonce aujourd’hui l’ouverture du protocole RTMP (Real Time Messaging Protocol) utilisé principalement dans Flash Media Server et LiveCycle Data Services. Ce protocole est utilisé pour transférer en temps réel au Flash Player des flux de données, de son et de vidéo.
L’ouverture du protocole RTMP s’inscrit dans la stratégie globale de la plateforme Flash. Ses spécifications seront publiées par Adobe au cours du premier semestre 2009 sur le site Adobe Developer Connection.

L’accès libre au protocole RTMP pour les développeurs est une étape supplémentaire d’Adobe entrant dans le cadre de l’Open Screen Project, une initiative visant à exploiter des contenus riches et des applications web sur la majorité des écrans des terminaux (informatiques, mobiles, produits électroniques grand public).

N’hésitez pas à réagir sur le forum

Le communiqué de presse original :

Adobe to Open Flash Platform Messaging Protocol

Publishing RTMP Advances Open Screen Project

Adobe Systems Incorporated (Nasdaq:ADBE) today announced plans to publish the Real-Time Messaging Protocol (RTMP) specification, which is designed for high-performance transmission of audio, video, and data between Adobe® Flash® Platform technologies. Providing developers and companies open and free access to RTMP is the latest advancement of the Open Screen Project, an industry-wide initiative to enable the delivery of rich multi-screen experiences built on a consistent runtime environment for Web browsing and standalone applications across personal computers, mobile devices, and consumer electronics.

The RTMP specification is expected to be posted on the Adobe Developer Connection in the first half of 2009.

« With the RTMP specification, developers and companies will be able to provide users with optimized audio, video and data streaming, no matter what kind of device the user is on or where the content is coming from, » said Adobe CTO Kevin Lynch. « Our ongoing commitment to openness is accelerating adoption of the Flash Platform by developers and resulting in a new generation of Web applications, content and video experiences that run reliably across operating systems and devices. »

RTMP provides an enhanced and efficient way to deliver rich content. Developers and companies will have free and open access to the documented RTMP specification to help enable unparalleled delivery of video, audio and data in the open AMF, SWF, FLV and F4V formats compatible with Adobe Flash Player.

To benefit customers who want to protect their content, the open RTMP specification will not include Adobe’s unique secure RTMP measures, nor will the license that accompanies the specification allow developers to circumvent such measures. However, developers will be free to use their own technological measures to secure content. The RTMP specification does not provide any requirement or restrictions on a developer’s own measures to secure content.

The Open Screen Project is an initiative with 20 major industry partners who are working together to provide a consistent runtime environment for Web browsing and standalone applications — taking advantage of Adobe Flash

Player and, in the future, Adobe® AIR™. This consistent runtime environment will remove barriers to publishing Web content and rich applications across desktops, mobile phones, televisions, and other consumer electronics.

The Adobe Flash Platform is the de facto standard for delivering breakthrough applications, content and video on the Web. Adobe Flash Player is on over 98 percent of connected computers and delivers more than 80 percent of Web video worldwide, ensuring that content and applications are presented consistently in the format users want. For more information on the Adobe Flash Platform, please visit www.adobe.com/flashplatform. For more information on the Open Screen Project, please visit: www.openscreenproject.org.

Nouveau FrameWork : Yii

RideKick — Tue, 23 Dec 2008 12:55:23 +0000

Les équipes du Framework PRADO ont récemment sorti son petit frère : Yii.

Si je dis son petit frère c’est juste parce qu’il est né de la même équipe .

Il semblerait qu’il soit plus puissant que Symfony lui même si on en croit le benchmark réalisé sur le site officiel.

Au niveau des fonctionnalités on retrouve les plus demandées :

– Localisation I18N/L10N
– Gestion du cache
– Entièrement Orienté Objet
– Support de JQuery
– Webservices

etc….

Un dépôt d’extensions est même intégré pour pouvoir ajouter les modules créés par les membres.

Vous pouvez donc aller le découvrir sur http://www.yiiframework.com/

et en discuter sur nos forums : La discussion

Défi PHP 2eme édition

RideKick — Wed, 03 Dec 2008 08:00:55 +0000

Bonjour a tous ,

La 2ème édition du défi PHP est sur les rails .
Elle aura lieu du 8/01/09 au 5/02/09 soit pendant 1 mois.

Les sujets seront annoncés le 8/01/09 au soir , la date limite de rendu des projets est fixée au 5/02/09 au soir.

Nous esperons que comme la dernière fois vous serez nombreux a y participer.

Rendez vous en 2009 !

Lien vers le topic du Forum

Les résumés internals@ sont déplacés vers le forum

Yogui — Mon, 13 Oct 2008 16:46:17 +0000

Les résumés de la liste internals@ pour PHP seront désormais sur le forum :

http://www.developpez.net/forums/d627347/php/langage/resumes-liste-internals/

N’hésitez pas à y mettre vos commentaires

Résumé internals@ des trois semaines précédentes

Yogui — Sun, 12 Oct 2008 18:55:26 +0000

Voici les points intéressants de la liste internals@ :

Le repository SVN de PHP.net est en ligne et à jour par rapport à CVS, mais il reste encore à réécrire les scripts d’ACL ;
L’analyse de la couverture de code (gcov) de PHP 4.4 (amplitude des tests par rapport au code source) sera bientôt supprimée ;
Sortie de PHP 5.2.7 RC1 ;
Zoë Slattery aprofondit ses connaissances des opcodes PHP ;
D’interminables discussions sur les espaces de noms pour PHP 5.3 ;