La réponse en images aux questions suivantes :
- Devenir du SGDB Mysql après son rachat par SUN
- Magento / Bargento
- Symfony vs Zend
Sources http://www.phptv.fr
PHPTV - Mai 2009
mai 18th, 2009PHPPowerPoint 0.1
mai 18th, 2009Après avoir manipulé des données Excel via PHPExcel, voilà qu’une nouvelle API vient de faire son apparition : PHPPowerPoint 0.1.
Tout comme son homologue PHPExcel, PHPPowerPoint vous permettra de générer des slides dynamiques (pptx)
Pour aller plus loin :
Règles de Développement Web - Erreurs à éviter
avril 16th, 2009Source : pouipouidesign.net, Traduction réalisée par Marie ALHOMME
Voici la traduction d’un article (amha) très intéressant de Roger Johansson sur son site 456 Berea Street.
Article d’origine
Ceci est une compilation des erreurs communes en développement web dont j’avais déja parlé dans les articles Web development mistakes et Web development mistakes, Redux.
Cette liste répertorie les erreurs qui sont communément rencontrées sur le Web, accompagnées d’une explication de la raison pour laquelle je les considère comme des erreurs. J’essaye aussi d’offrir un moyen d’éviter chaque erreur, ainsi que des liens vers plus d’informations sur certaines des erreurs.
Confusion de DOCTYPE
Manquant complètement, incorrect, ou au mauvais endroit. J’ai vu du HTML 4.0 Transitional utilisé dans des documents contenant du code XHTML ainsi que dans des documents avec <frameset>, des déclarations de DOCTYPE apparaissant après la baslise <html> d’ouverture, et des DOCTYPES incomplets.
Pourquoi ?
Deux raisons. D’abord c’est requit comme déclaré dans les Spécifications HTML 4.01 du W3C (en) ainsi que dans les Spécifications XHTML 1.0 du W3 (en). Ensuite, les navigateurs web modernes utilisent le DOCTYPE spécifié pour décider du mode de rendu qu’ils utilisent. Ceci est aussi connu sous le nom de “DOCTYPE switching”. Afin d’obtenir des résultats plus homogènes d’un navigateur à l’autre, surtout quand on utilise les CSS, vous voudrez que les navigateurs utilisent le mode « Standard ». Plus d’information sur le “DOCTYPE switching” peut être trouvée dans les articles : Réparez votre site avec le bon DOCTYPE ! (en) et Activer le bon mode de mise en page en utilisant la déclaration de DOCTYPE (en).
<span> mania
Une façon commune de donner un style à un element avec les CSS est de l’encapsuler dans un element <span> avec un attribut class et d’utiliser cela pour le lier au style. Je suis sûr que nous avons tous vu des choses comme <span class=”titre”> et <span class=”textecontenu”>.
Pourquoi ?
Dans la plupart des cas, c’est complètement inutile, ça n’a aucune valeur sémantique, et ça ne fait qu’encombrer le code. Utilisez des balises de titre (hx) pour les titres, mettez les paragraphes dans des balises de paragraphe, codez vos listes avec les éléments HTML de liste. Utilisez les CSS pour appliquer des styles à ces éléments. Si nécessaire, ajoutez des attributs de class ou d’id.
Penser (trop) visuellement
Traiter le web comme du WYSIWYG (“What You See Is What You Get”) : commencer en se concentrant sur l’aspect des éléments au lieu de réfléchir à la structure d’abord et à la presentation après.
Pourquoi ?
Bien que la plupart des gens voient, tous ne le peuvent pas. Et il n’y a aucun moyen de rendre le site WYSIWYG. Il y aura toujours des variations tant que les gens n’utiliseront pas tous les mêmes : navigateur, système d’exploitation, résolution, taille de fenêtre, calibration chromatique et taille de typo. Le Web n’est PAS du print ou de la télévision. Faites des mises en pages flexibles !
Manque de sémantique
Code non-sémantique. Baser son choix de l’élément HTML à utiliser en fonction de son apparence par défaut dans la plupart des navigateurs graphiques, au lieu de le faire en fonction du sens de l’élément.
Pourquoi ?
Cette erreur est très proche de la “<span> mania” en ce qu’elle ne correspond pas à une utilisation correcte des éléments HTML préexistants afin de donner un sens au contenu. Sans un code HTML sémantique, il est bien plus difficile pour les agents utilisateurs non visuels [NDLT : navigateurs textes ou oraux par exemple] de donner un sens au contenu. Le code HTML sémantique tend aussi à être facile à styler avec les CSS.
Disparités d’encodages de caractères
Spécifier un encodage de caractère dans le header HTTP envoyé par le serveur, et en utiliser un autre dans le document. Ceci peut troubler les navigateurs et leur faire afficher le document incorrectement.
Pourquoi ?
Parce que vous vous voulez vous assurer que vos visiteurs peuvent lire votre contenu.
Mauvais attributs alt
Manquants ou inutiles. Des éléments <img> auxquels manque un attribut alt peuvent se trouver par milliards sur le web. Un peu moins fréquents sont les attributs aux valeurs inutiles comme “spacer GIF utilisé pour rendre la mise en page plus jolie ”, “grosse puce bleue avec ombré ”, et “Image JPEG, 123 Ko”. Rappelez-vous que l’attribut alt est requis pour les éléments <img> et <area>.
Pourquoi ?
C’est requis (en), et sans eux toute information dans l’image sera invisible pour les lecteurs d’écrans, les navigateurs texte, les robots de moteurs de recherche, ou les utilisateurs chez qui les images sont désactivées. Notez que le texte alternatif devrait être approprié. Ne spécifier pas de texte alternatif pour les images décoratives ou les images utilisées pour la mise en page. Dans ces cas, spécifiez une chaîne vide : alt=”".
Attributs id et class invalides
Utilisation multiple d’une même valeur pour l’attribut id. Caractères invalides utilisés dans les attributs de class et d’id et les sélecteurs CSS.
Pour les CSS (Syntaxe et types de données de base en CSS 2.1 (en)): En CSS 2.1, les identifiants (incluant les noms d’éléments, les class et les id) ne peuvent contenir que les caractères [A-Za-z0-9] et les 10646 caractères ISO U+00A1 et supérieur, plus le tiret (-) et le tiret bas (_); ils ne peuvent commencer par un chiffre.
Pour l’HTML (Types de données de base en HTML (en)): Les ID et les NAME doivent commencer par une letter ([A-Za-z]) et peuvent être suivis de n’importe quel nombre de lettres, chiffres ([0-9]), tirets (”-”), tirets bas(”_”), deux-points (”:”), et points (”.”).
Pourquoi ?
Les navigateurs qui suivent les spécifications n’afficheront pas le document comment vous l’aviez prévu. Si un document a de multiples occurrences de la meme valeur d’id, n’importe quel JavaScript utilisant cette valeur a toute les chances de ne pas fonctionner ou de fonctionner de manière imprévisible.
Reconnaissance du navigateur (“Browser sniffing”)
Utiliser des scripts, côté serveur ou client, de façon à détecter le navigateur du visiteur et lui envoyer ou lui faire exécuter du code spécifique à ce navigateur. Echoue très souvent pour des raisons telles que : nouveaux navigateurs, navigateurs mis à jour, et le « user agent spoofing » [NDLT : fonction qui permet à un navigateur de se faire passer pour un autre] (Opera fait ceci par défaut [NDLT : en se faisant passer pour IE]).
Pourquoi ?
Cela complexifie le processus inutilement et finira par casser à la fin.
Unités manquantes en CSS
Les valeurs de longueur (measures verticals ou horizontals) requièrent des unites en CSS, sauf quand la valeur est zéro. C’est différent d’en HTML, où vous pouvez taper width=”10″. En CSS, cela doit être écrit width:10px; (ou n’importe quelle unité que vous utilisez).
Pourquoi ?
Cela ne marchera pas dans les navigateurs qui suivent les spécifications (en).
CSS spécifiques à un navigateur
Styler les barres de scroll, les expressions, les filtres, etc. Les CSS propriétaires qui ne fonctionnent que dans Internet Explorer. Ce n’est pas valide, en plus.
Pourquoi ?
Cela ne marchera que dans un navigateur spécifique. Si vous devez réellement utiliser des CSS spécifiques à IE, déplacez-les dans un fichier séparé et utilisez les commentaires conditionnels (en), ou une autre méthode, afin de vous assurer que seulement IE verra les règles invalides.
Dépendance à JavaScript
Rendre un site dependant de JavaScript. Plus de personnes que vous ne le voudriez utilisent un navigateur sans support du JavaScript, ou ont désactivé le JavaScript dans leur navigateur. Les statistiques actuelles (Statistiques navigateurs sur W3Schools (en), TheCounter.com) indiquent que cela concerne 8 à 10% des utilisateurs. Les robots des moteurs de recherche ne savant présentement pas bien interpreter le JavaScript non plus, même s’il y a des rapports selon lesquels Google travaille au support de JavaScript pour le Googlebot. Si votre site nécessite du JavaScript pour naviguer, n’espérez pas de bons classements dans les moteurs de recherche.
Pourquoi ?
Non accessible et mauvais pour les classements dans les moteurs de recherche.
Dépendance à Flash
Supposer que tout le monde a Flash installé. Ce n’est pas le cas. Et la plupart des robots des moteurs de recherche n’ont plus (Google aurait commencé à expérimenter avec l’indexage des fichiers Flash, mais il recommande que vous vous assuriez que tous votre contenu textuel et votre navigation soit disponibles dans des fichiers HTML), alors si votre site entier, ou votre navigation, dépend de la présence de Flash, vous n’allez pas avoir beaucoup de succès auprès des moteurs de recherche.
Pourquoi ?
Inaccessible et mauvais pour les classements dans les moteurs de recherche. Je ne dis pas que vous ne devriez pas utiliser Flash du tout, mais seulement qu’il faut le faire raisonnablement.
Texte en image
Faire des images du texte et ne pas fournir une alternative plus accessible. Non seulement il est plus long pour les utilisateurs de charger des images que du texte, mais vous rendez aussi impossible de copier du texte pour tous les visiteurs, ainsi que, pour la plupart d’entre eux, de le zoomer.
Pourquoi ?
Inaccessible, augmente le temps de chargement, mauvais pour les classements dans les moteurs de recherche.
Mauvais formulaires
Formulaires non accessibles et difficiles à utiliser. Apprenez à utiliser les éléments <label>, <fieldset>, et <legend>, et n’utilisez pas de bouton “Reset” (« remise à zéro »).
Pourquoi ?
Inaccessible, diminue l’utilisabilité. Lisez Créer des Formulaires Accessibles (en), De Meilleurs Formulaires Accessibles (en), et Boutons Reset et Cancel (en) afin d’en savoir plus sur la creation de formulaires accessibles et utilisables.
HTML à l’ancienne
Tables multiples imbriquées, spacers GIF, éléments <font>, code de présentation. Si commun que je n’ai pas vraiment besoin de le mentionner ici.
Pourquoi ?
Complexité accrue, pages artificiellement gonflées, lent, inaccessible, mauvais pour les classements dans les moteurs de recherche.
Etre “IE-centrique”
Coder pour IE/Win d’abord, puis ajuster pour les autres navigateurs s’il reste du temps.
Pourquoi ?
Cela prend plus de temps, encourage les mauvaises habitudes de codage. IE/Win est connu pour accepter un code HTML invalide et bâclé, qui ne fonctionne pas (ou mal) dans de nombreux autres navigateurs. IE accepte aussi du code HTML bien formé et valide, qui fonctionne dans tous les navigateurs, donc en utilisant de l’HTML valide vous rendez tous les navigateurs heureux, et cela ne vous prendra pas plus de temps ou ne coûtera pas plus cher. Voir aussi Le Facteur IE (en).
Attributs HTML invalides
Utiliser des attributes dépréciés ou spécifiques à un navigateur comme marginwidth, leftmargin, language, height pour les éléments <table>, border pour les éléments <img>, etc.
Pourquoi ?
Invalide et inutile. Utilisez plutôt les CSS. Pour les éléments <script>, utilisez type, et non language, afin de spécifier le langage de script utilisé (presque toujours JavaScript).
Signes & (ampersands, ou esperluette en français) non encodés
Beaucoup d’URI contiennent de longues chaines de requêtes avec des esperluettes non encodées (&). Ceci n’est pas valide, et peut causer des problèmes (en). Les esperluettes doivent être écrites &.
Pourquoi ?
Une explication ainsi qu’un exemple de ce qui peut mal se passer peuvent être trouvées dans Esperluettes et validation (en).
Cadres (Frames)
Utiliser des cadres pour séparer l’espace en plusieurs documents indépendants.
Pourquoi ?
Tout d’abord, laissez-moi dire que les cadres peuvent être utiles, utilisés de la bonne manière, dans les intranets et certaines applications web. Pour un site publique, cependant, les cadres posent trop de problèmes d’accessibilité et d’utilisabilité. Problèmes d’ajout aux favoris, difficultés d’impression, problèmes avec les liens profonds [NDLT : Deep Linking (en)], et l’obligation de trouver des solutions de contournement pour les moteurs de recherche, sont quelques-uns des inconvénients de l’utilisation des cadres.
Tableaux de données inaccessibles
Les tableaux contenant des données tabulaires, mais dont le code correspond à des tableaux utilisés pour la mise en page, en n’utilisant aucun des nombreux éléments et attributs disponibles afin de rendre les tableaux structurés et accessibles.
Pourquoi ?
Les lecteurs d’écran et autres technologies d’assistance n’ont aucun moyen de donner un sens à un tableau de données à moins qu’il soit codé correctement. Un tas de liens décrivant comment coder des tableaux de données peuvent être trouvés dans A table, s’il vous plaît (en), sur le site du Web Standards Project.
Divitis et classitis
Lié à la <span> mania. Ajouter des éléments <div> et des attributs class non nécessaires.
Pourquoi ?
Voir “<span> mania” et “Manque de sémantique”.
Largeur fixe trop large
Si vous utilisez un design à largeur fixe, ne le faites pas trop large. Note : Je ne rentrerai pas dans le débat sur fixe vs fluide ici.
Pourquoi ?
Si votre largeur spécifiée est plus large que la place disponible sur l’écran de vos visiteurs, vous les forcez à scroller horizontalement, ce qui est vraiment mauvais pour l’utilisabilité.
Noms d’id et de class vagues et/ou de présentation
Nommer une class ou une id basée sur son apparence plutôt que son action.
Pourquoi ?
C’est chercher les ennuis lors d’une refonte graphique. Une class nommée bleularge peut se retrouver à render du texte petit et rouge. Un id nommé colgauche pourrait être affiché sur la droite.
Pas de couleur pour le fond
Ne pas déclarer de couleur de fond pour l’élément body.
Pourquoi ?
Beaucoup d’utilisateurs n’ont pas leur navigateur paramétré pour afficher la même couleur de fond que vous.
XHTML mal formé
Utiliser de l’XHTML qui n’est pas bien formé (en).
Pourquoi ?
Si XHTML est envoyé comme application/xhtml+xml, ce qu’il devrait être, les navigateurs se confirmant strictement aux standards, comme ceux basés sur Mozilla, ne sauront pas afficher de l’XHTML mal formé. Notez que ce site n’envoie pas tous les documents comme application/xhtml+xml, pour certaines raisons expliquées dans mon article sur la Négotiation de contenu (en).
Couleurs incomplètes pour les champs de texte
Spécifier uniquement la couleur du fond ou celle du texte pour les champs de formulaire, surtout les champs de texte uni- et multi-lignes (<input type=”text”> et <textarea>).
Pourquoi ?
Certaines personnes ont parametré leur navigateur ou leur système d’exploitation afin qu’ils affichent des couleurs inversées. Le réglage par défaut d’un champ de texte serait alors texte blanc sur un fond noir, au lieu de texte noir sur fond blanc. Si vous choisissez le gris foncé pour le texte mais ne spécifiez pas de couleur pour le fond, les visiteurs avec les couleurs inversées auront un texte gris foncé sur un fond noir, ce qu’il est quasiment impossible de lire.L’inverse causera aussi des problèmes : spécifier un fond de couleur gris pâle sans spécifier la couleur du texte résultera en un texte blanc sur un fond gris clair.
Spécifiez toujours soit la couleur du texte et celle du fond, soit aucune des deux, pour les champs de texte.
Voilà une liste plutôt longue des choses dont il faut se méfier. Evitez les toutes et vous vous débrouillerez très bien. Si vous faites actuellement une de ces erreurs, eh bien si ça peut vous consoler j’ai moi-même été coupable d’en avoir fait une grande quantité à un moment donné. Avec un peu de chance, cette liste vous aidera à faire moins d’erreurs dans le futur.
Info développement PECL
mars 24th, 2009Les dernières MAJ du mois de mars
- pdflib : création de fichiers PDF
- imagick : interface avec la bibliothèque graphique ImageMagick
- oci8 : fonctions OCI8
- timezonedb : base de données de fuseaux horaires pour PHP
- geoip : Indique la localisation géographique d’une IP
- uploadprogress : suivi des téléchargements de fichiers type Ajax
- spidermonkey : JavaScript engine for PHP
- mongo : Mongo Database Driver
- selinux : SELinux binding for PHP script language
- markdown : a fast Markdown parser
- xhprof : XHProf: A Hierarchical Profiler for PHP
(Sources nexen)
GoogleStreetView
mars 24th, 2009Google poursuit son tour de France. Après avoir inauguré son service Street View dans l’Hexagone en 2008 à l’occasion du Tour de France, le groupe américain vient encore de l’enrichir de 33 villes françaises supplémentaires. Désormais, c’est près d’une soixantaine de grandes villes françaises qui peut être visitées sur Internet. Voici un tour de France non exhaustif des nouvelles villes sillonnées par Google.
Lire l’article associé(Sources JDNET)
Internet Explorer 8
mars 24th, 2009La version finale d’Internet Explorer 8 renforce la sécurisation de la navigation contre le phishing et les codes malveillants. Sans faire pour autant l’impasse sur le respect des standards CSS 2.1 et DOM.Le processus de validation d’un site à IDEP Multimédia inclura désormais IE8 dans les tests de compatibilité étant donné que IE8 sera très prochainement installé par défaut sur les nouvelles machines des constructeurs.
Article associé (Sources JDNET)
Les développeurs préfèrent PHP
mars 24th, 2009Une étude a réalisée par le site de « The Registrer » auprès de 500 développeurs concernant la satisfaction de l’utilisation des langages de scripts.
Cette étude porte sur les langages PHP, Ruby, Perl, Javascript, VB Script… et sur différentes catégories (L’utilisation, la communauté, la sécurité, performance,etc… )
Le langage qui a reçu la meilleure note est le langage PHP.
http://www.theregister.co.uk/2009/03/05/evans_data_gentlemen_prefer_php/
(Source The Register – theregister.co.uk)
Google Adsense Mobile pour vos blogs
mars 24th, 2009Avec les nouvelles générations de téléphones portables, une nouvelle manière de naviguer sur le web apparaît.
SeoMan montre comment intégrer facilement Google Adsense Mobile sur votre blog avec l’utilisation en PHP du plugin MobileRadar de Wordpress
http://bababillgates.free.fr/index.php/google-adsense-mobile-14-etapes-pour-lintegrer-sur-votre-blog/
Quel IDE Choisir pour développer en PHP ?
mars 24th, 2009Le choix d’un IDE (http://fr.wikipedia.org/wiki/Environnement_de_d%C3%A9veloppement_int%C3%A9gr%C3%A9) au quotidien est impératif pour travailler sur des projets en POO ou non. La question du logiciel gratuit ou non se pose.
IDEP Multimédia vous conseille de lire cet article pour vous aider à orienter vos choix et vos tests
http://www.smashingmagazine.com/2009/02/08/50-extremely-useful-javascript-tools/
(Source www.smashingmagazine.com)
Le choix d’Idep Multimédia pour développer en PHP
mars 24th, 2009Depuis sa création, Idep Multimédia a fait le choix du PHP pour développer les sites de ses partenaires.
IDEP MULTIMEDIA
«[…] Il a été conçu pour permettre la création d’applications dynamiques, le plus souvent dédiées au Web. PHP est très majoritairement installé sur un serveur Apache, mais peut être installé sur les autres principaux serveurs HTTP du marché, par exemple IIS. Ce couplage permet de récupérer des informations issues d’une base de données, d’un système de fichiers (contenu de fichiers et de l’arborescence) ou plus simplement des données envoyées par le navigateur afin d’être interprétées ou stockées pour une utilisation ultérieure. […]»
(Source Wikipédia - http://fr.wikipedia.org/wiki/PHP)
Idep Multimédia s’appuie sur de nombreux modules opensource écrits en PHP pour ajouter des fonctionnalités sur les sites que nous développons :
- Forum
- Wiki
- ….