Lire la suite
Oui, les billets Symfony commençaient à me manquer. Mais difficile de trouver et le temps et la ressource pour en faire. Mais voici une petite astuce illustrée qui permet de trouver une application au type array de Doctrine tout en simplifiant une problématique. Tout ce que j’aime.
Oui, je commence à parler de Doctrine de plus en plus vu que je commence à l’utiliser à grande échelle au boulot. Et il y a un détail où j’ai encore du mal, c’est l’opacité de cet ORM comparé à son prédécesseur dans Symfony, Propel.
On se rappelle tous (enfin je parle au passé, mais Propel n’est pas mort hein :p) qu’on avait tout à disposition dans le BasePeer de notre modèle, les accesseurs, les modificateurs et quasi toutes les méthodes dont on pouvait avoir besoin. Avec Doctrine, la donne a changé, tant cet ORM est codé différemment.
On se retrouve du coup un peu perdu parfois, sans trop savoir ce qu’on peut utiliser. Et là, il faut bien sûr jeter un œil à l’API Doctrine. Mais on le sait tous, on a pas toujours le temps! Du coup, au travers de mes recherches, j’ai trouvé quelques petites méthodes que j’utilise régulièrement et dont je vais vous parler. Lire la suite
On emploie tous je pense, assez couramment maintenant, le widget sfWidgetFormInputFileEditable qui permet de rajouter quelques fonctionnalités à un widget d’upload classique, en l’occurrence visualisation et suppression. Le souci que j’ai rencontré récemment, c’est par contre la personnalisation du nom du fichier ainsi généré.
En effet, par défaut celui-ci est une empreinte sha1 généré aléatoirement, ce qui convient pour la majeure partie des cas, mais parfois ne suffit pas. Mais là encore Symfony étonne par le mécanisme mis en place pour contourner cette problématique, encore faut-il le savoir malheureusement. Lire la suite
Comme dit le proverbe, billet du mardi, billet symfony… Bon on va dire que c’est un nouveau proverbe mais pour le coup, on va continuer cet adage avec au programme aujourd’hui les possibilités offertes par symfony pour modifier le code HTML construit par ses fameux widgets de son système de formulaire.
Plus mon nombre de projets défile sous Symfony et plus j’essaye d’éviter de faire des choses hors framework, mais plutôt de voir comment on pourrait le régler via le framework. Avant, quand un problème se présentait, j’optais souvent pour une solution alternative quitte à mettre de côté pour une petite fonction la philosophie Symfony. Mais voilà, je l’aime moi, cette philosophie et au fur et à mesure, j’ai décidé de mettre de plus en plus les mains dans la cambouis et les yeux dans le code source, pour résoudre mes problèmes. Lire la suite
Dans le genre, méthode symfony dont on ne parle pas qui peuvent être utiles, voici preExecute et son copain postExecute toutes les deux, méthodes de sfAction.
Comme leur nom le laisse à penser, ce sont des méthodes qui seront appeler en amont et en aval de l’exécution d’une action. Je n’ai pas vraiment d’idée d’utilisation à l’heure où j’écris mais dans un souci de factorisation, je trouve le concept intéressant et c’est bien avec ce genre de méthodes que je trouve Symfony si bien pensé.
Quelqu’un s’en est déjà servi? Une utilisation intéressante qui gagne à être connue?
Votre projet est en plein sprint, les releases de corrections s’enchainent et vous devez soumettre le résultat à chaque fois à votre client. Et pourtant il y a un mécanisme des navigateurs qu’on adore en tant qu’utilisateur mais qui gène parfois en tant que développeur, la mise en cache des CSS.
Quoi de plus frustrant d’avoir en premier retour de votre client Euh, pourquoi l’image est au milieu de l’écran?
alors que vous venez de passer les dernières heures à la mettre au bon endroit en retouchant votre CSS. Bien sûr vous lancez rapidement le cri de guerre adéquat F5!
et la magie opère enfin.
Mais ne serait-il pas plus plaisant que d’obtenir dès le premier clic, le bon résultat? Lire la suite
Il y a pour cela une astuce, que bon nombre connaisse, mais qui dans un contexte de développement professionnel, est souvent lourde à mettre en place: changer le nom de votre CSS pour forcer le navigateur à la recharger et ainsi laisser apparaitre vos modifications du premier coup.
Tous les Linuxiens, en particulier les développeurs web ont du passer le pas un jour, installer une solution le permettant de tester leur page web dans ces magnifique navigateurs qui ralentissent l’avancée technologique du web, j’ai nommée IE6 et IE7.
Là où la virtualisation se banalise grâce à des logiciels comme VirtualBox, certains utilisent encore des émulateurs dont le célèbre ie4linux.
Et bien, l’alternative pour Mac OS X existe, preuve que la pomme a quand même bien fait les choses. Et pour l’installer rien de plus simple. Lire la suite
Un autre domaine assez controversé dans le web, ce sont les formats d’images. Bien longtemps, grand chouchou des webmaster, le GIF a régné en maître, de part sa technologie, une compression sans perte qui gèrait le canal alpha et même l’animation!
Son principal problème était son brevet, qui a trainé jusqu’en 2004, le rendant ennemi numéro 1 des libristes du web. Pendant ce temps, tapis dans l’ombre, le PNG a commencé à monter en puissance, d’abord appuyé par le W3C puis certifié ISO en 2004.
Son principal intérêt, un gif amélioré et un format ouvert. Amélioré car il ne s’arrête pas aux 8bits de couleurs du GIF, mais va jusqu’à 32, permettant même de gérer totalement la transparence d’une image et à image égale il surpasse le GIF en poids d’image.
Malheureusement, trop mis en avant dès sa sortie, le PNG a été proclamé messie et tueur également du format JPEG alors qu’il n’en avait pas la possibilité. En effet, le jpeg tire son succès dans la compression de photo, là où son algorithme de compression avec perte (grosse différence comparé au PNG) pouvait pleinement s’exprimer. A photo égale, le PNG se retrouve donc logiquement loin derrière.
On l’a alors rangé dans le catalogue format non optimisé, trop lourd, sans compter avec ces problèmes relationnels avec Photoshop et Internet Explorer.
Mais comme tous les formats ouverts, le PNG a ses fans et certains réalisent des choses assez folles comme ce cher Smush it qui permet en 1 clic après installation du plugin firefox correspondant d’optimiser toutes les images d’un site, vous les mettant alors à disposition, et en PNG bien sûr.
Voila le résultat pour amicalement web:
Un des principaux manques actuels du CSS 2, c’est bien la gestion de la police.
Il n’est pas encore possible d’imposer une police à l’internaute[1] mais seulement de lui en suggérer un certain nombre que le navigateur parsera dans l’ordre donné jusqu’à en trouver une que le système d’exploitation possède. Mais avec la montée en puissance, lente mais régulière des systèmes autre que Windows, il peut devenir un vrai casse-tête de trouver une police un peu évoluée que chacun pourra afficher.
En fait le problème se pose surtout pour les linuxiens, et même le paquet msttcorefonts ne résous pas ce problème entièrement, en plus d’obliger les partisans du pingouin à installer un paquet supplémentaire.
Mais le web regorge de bonnes volontés, et je suis tombé sur un billet en anglais qui tente de trouver des équivalents à ce cher Arial, Helvetica, Lucida sous linux en natif.
Au final, j’ai opté personnellement pour le couple Lucida Sans/Mukti Narrow pour le texte et Helvetica/FreeSans pour les titres. Après quelques tests, le résultat est tout à fait acceptable sur mon Ubuntu et permet de garder un peu plus le contrôle sur la charte graphique désirée.
Les conditions font partie intégrante de tous les langages de programmation, PHP ne déroge pas à la règle.
Cependant il n’est pas rare qu’elles gâchent la lisibilité d’un code quand elles s’imbriquent ou quand les différents états sont à plusieurs dizaines de lignes d’écart.
Un moyen simple d’y voir plus clair et de tourner vos conditions différemment.
Par exemple, on a souvent tendance à écrire:
<?php if ($condition) { /* Tout mon traitement qui peut faire plusieurs dizaines de ligne */ } else { /* Traitement de l'erreur, par exemple */ return false ; } ?>
Au final, la condition n’est utilisée que pour gérer le cas d’erreur, mais celui-ci se retrouve retranché en bas de script.
Pour gagner en lisibilité, on pourrait donc écrire:
<?php if (!$condition) { /* Traitement de l'erreur, par exemple */ return false ; } /* Tout mon traitement qui peut faire plusieurs dizaines de ligne */ ?>
La gestion de notre erreur, est maintenant dans la continuité de notre script et se révèle beaucoup plus confortable à lire. Attention toutefois, ce genre de pratique demande à ce que votre gestion d’erreur coupe l’exécution du script avec en général l’utilisation de return.
Abonnez-vous pour suivre l'actualité du blog
Vous devriez me suivre sur twitter
Recevez les nouveaux articles par mail