- Publié le 08 avril 2009 à 00:22
Il n'y a pas que des améliorations de performances dans eZ Publish 4.1. L'annonce de la sortie de la version 4.1 liste les plus grosses nouveautés (stale cache, object states, ...) et d'autres améliorations attendues depuis un bon moment. Je pense en particulier à l'ajout de déclencheurs sur d'autres opérations que l'affichage d'un objet (content/read), la publication (content/publish) ou ceux dédiés au module de boutique. Mais eZ Publish 4.1 apporte aussi d'autres améliorations qui sont passées pour le moment un peu inaperçues comme l'amélioration des content edit handler ou les extensions de type output filter.
Validation avec un content edit handler
Jusqu'à eZ Publish 4.0 un content edit handler permettait uniquement lancer un bout de PHP au moment de la publication d'un contenu. Il s'agit d'un mécanisme apparu dans eZ Publish 3.8 qui permet d'implémenter tout un tas de fonctionnalités comme la mise à jour d'un cache spécifique, la publication à partir d'une date renseignée dans un attribut, la création d'un espace personnel lors de l'ajout d'un utilisateur, ... J'ai toujours vu ce mécanisme comme une sorte d'évènement de workflow post publish en beaucoup plus simple (pas de code de retour, pas de syntaxe alambiquée, pas de possibilité de laisser le travail à script cron...).
Dans eZ Publish 4.1, il est maintenant possible d'implémenter une méthode de validation dans un content edit handler, en fonction du retour de celle-ci, l'objet part en publication, sinon le formulaire affiche le/les messages comme lorsqu'on oublie de remplir un champ obligatoire par exemple. Dans certains cas, ce nouveau mécanisme peut largement simplifier les choses notamment en permettant la vérification de règles syntaxiques supplémentaires sans nécessiter le développement d'un datatype spécifique ce qui est parfois un peu lourd pour juste ajouter une validation simple (validation d'un code postal, d'une longueur minimale d'une ligne de texte, d'un domaine particulier pour un email, ...)
Extension output filter
Il s'agit d'un nouveau type d'extension qui permet d'ajouter un traitement sur le code de la page entière. La documentation dans le SVN de cette nouvelle fonctionnalité donne comme exemple la réécriture des URL des composants de la page en fonction de la position géographique. Pour les validatorophiles, on peut aussi imaginer corriger les éventuels problèmes de validation (X)HTML grâce à un filtre utilisant l'extension php-tidy ou encore remplacer des tags prédéfinis par des éléments générés par un autre système (une version PHP des SSI ou d'ESI simpliste). Bien évidemment comme cette fonctionnalité permet de traiter l'ensemble du code de la page, il faut se méfier des effets néfastes sur le temps de génération des pages.
- Publié le 27 janvier 2009 à 17:59
Suite de la série de billets sur la réalisation du Planet eZ Publish.fr avec dans celui ci quelques notes sur les modules/vues spécifiques ainsi que sur la réalisation des templates.
I. Organisation et Import des articles
II. Modules/vues sur mesure et templates
III. Performances : caches et compagnie
Modules / vues sur mesure
Pour le moment, seuls deux vues spécifiques sont utilisées sur le site.
feed/planet
Cette vue sert à générer le flux RSS du Planet. Comme pour l'import RSS, le composant Feed des eZ Components est utilisé. L'intérêt principal par rapport à l'export RSS de base est la possibilité d'ajouter la balise dc:author avec le nom du site (l'objet parent dans le cas du Planet). Cette vue implémente également un système de cache sur le même principe que le cache de vue. Ce cache est vidé et est re-généré par le script d'import RSS alors que le cache de l'export RSS par défaut expire au bout d'un temps fixe.
planet/search
Cette vue reproduit la vue de recherche par défaut en forçant la recherche dans une sous-arborescence sans avoir besoin de passer le paramètre SubTreeArray. Contrairement à content/search, elle permet également l'utilisation des persistent variables comme sur content/view.
Templates et opérateur
Les templates pour ce site sont assez classiques et plutôt simples compte tenu de la charte graphique basique. Seule « astuce », chaque vue full fixe deux entrées dans les persistent variables ce qui permet de générer un titre et une description pertinents sans aucun fetch supplémentaire dans le pagelayout qui serait synonyme de requêtes SQL et/ou de cache supplémentaire à gérer (voir les dernières lignes du template planet.tpl et les premières du pagelayout.tpl par exemple).
Le seul opérateur spécifique est l'opérateur clean_rewrite_xhtml utilisé à la place de l'opérateur wash pour afficher les attributs Text block contenant le texte issu des flux RSS. Cet opérateur a plusieurs fonctions :
- rendre valide le code XHTML avec le module PHP Tidy
- réécrire les éventuels URLs relatives à site (images et liens)
- supprimer toute trace de Javascript grâce à quelques expressions XPath.
- Publié le 05 août 2008 à 22:48
Nouveau design, nouvelles couleurs, nouveaux templates, nouveaux bugs peut-être mais toujours eZ Publish ! ça me démangeait depuis un moment, je repoussais toujours en attendant l'intégration du composant Template d'eZ Components bien plus performant mais vue la nouvelle roadmap d'eZ Publish et le projet V, ce n'est pas encore pour tout de suite !
J'espère donc que c'est plus clair et lisible, moins buggé sous Internet Explorer notamment (fini les Peekaboo normalement) et surtout bien plus performant avec une gestion des caches plus fines (oui j'ai appris quelques trucs depuis Août 2006).
- Publié le 02 février 2008 à 22:30
Vu chez Laurent Jouanneau, un test Acid3 est en cours d'écriture. Pour rappel, les tests Acid visent à mettre à l'épreuve les navigateurs en mettant en évidence leurs lacunes en terme de support des standards du web à un moment donné. Le premier test Acid était focalisé sur les modèles de boîtes, le deuxième sur le support du CSS et des images PNG. Le dernier en cours d'écriture se focalisent sur quelques propriétés avancées de CSS2 et surtout sur le support du DOM en javascript (il y a plus de 3000 lignes de javascript dans le test...).
Aucun navigateur ne réussit ce test et c'est bien sûr fait exprès pour pousser les développeurs à corriger les bugs. Pour le moment, Firefox 2 et 3 s'en sortent les mieux avec à peine plus que la moyenne et comme d'habitude les Internet Explorer font partie des pires... Plutôt normal pour IE6, mais très décevant pour Internet Explorer 7. Je me souviens que la dernière fois que j'ai développé une application utilisant abondamment (abusivement ?) javascript et le DOM, IE était un vrai cauchemar dès qu'il s'agissait de faire des choses avancées, pire que dans le domaine du montage HTML/CSS... Consolons nous, Microsoft a annoncé qu'une version interne du futur Internet Explorer 8 passait le test Acid2, avec un peu de chance cela aura des effets bénéfiques sur les fonctionnalités testées dans Acid3 et avec beaucoup de chance, ils auront le temps d'ajouter un support décent du DOM dans IE8...
- Publié le 20 novembre 2007 à 00:21
Encore une belle Microsofterie qui n'est certes pas toute neuve mais qui commence à avoir des effets (pervers) puisque les concepteurs d'Outlook 2007 se sont dit qu'il serait bien d'utiliser le moteur de Word pour rendre les mails HTML à la place du moteur d'Internet Explorer pour, paraît il, améliorer la sécurité de leur logiciel malgré les tares de ce pauvre traitement de texte dans le domaine du rendu HTML et CSS...
Mais au moins, avant aujourd'hui, j'étais ignorant, je croyais que le navigateur le plus sécurisé produit par Microsoft ces derniers temps était Internet Explorer 7, mais maintenant je sais et vous pouvez tous le répéter autour de vous : " Le navigateur le plus sécurisé produit par Microsoft est ... Word 2007" :-) Y'a du boulot
