Tout est objet … et on ne s’en plaint pas!
Ce nouveau post est une suite logique à mon premier article décrivant, après quelques semaines d’utilisation, mes impressions sous eZ Publish. Il peut être intéressant de le lire, surtout si vous ne connaissez pas encore l’outil ou que vous êtes entrain de le découvrir. Ici, je vais aborder certains points techniques pouvant vous aider à appréhender l’organisation même du framework.
Sous eZ Publish l’arborescence de vos projets s’organisera toujours autour de nœuds. Tout comme sur votre OS favori, un nœud pourra prendre la forme d’un répertoire ou d’un fichier qui sera alors appelé un objet. Un objet ne peut exister sans nœud, et c’est pourquoi un nœud fera toujours référence à un objet grâce à son id. Ces notions sont très importantes à assimiler car lors de vos futurs développements vous vous apercevrez très vite que toutes vos vues s’organiseront toujours autour de ces nœuds. Et mes classes de contenu alors ? Par abus de langage, un objet est une classe, à la différence qu’un objet existe sous un nœud (il a été créé), et qu’une classe n’est rien d’autre qu’un modèle de données.
Pour schématiser ces notions:
- Accueil
- Rubrique 1
- Rubrique 2
- Page
Accueil est un nœud d’id 2, on l’appelle le RootNode car c’est le nœud le plus haut dans votre arborescence, il est normalement impossible de le supprimer et il existe par défaut. Ce nœud fait référence à un objet de type homepage, et si vous avez suivi jusqu’à présent, homepage est une classe de contenu. Un nœud ou plus précisément une classe de contenu pourra adopter le comportement de conteneur, c’est le cas de notre RootNode capable de contenir des enfants (Rubrique 1, Rubrique 2 etc…). Ce comportement sera à signaler lors de la création/modification de vos classes de contenu en cochant simplement la case conteneur. De ce fait, même un objet de type page pourra avoir des enfants!
- Un noeud est représenté par son node_id et fait référence à un objet grâce à son object_id ;
- Un objet est représenté par son object_id et fait référence à une classe par son class_id ;
- Une classe de contenu est représentée par son class_id, c’est un modèle de données constitué d’un ou plusieurs attributs typés (ligne de texte, bloc de texte, champ mail, bloc XML etc…), on les appelle datatypes.
Si vous voulez aller plus loin, sachez que même les datatypes ont un id, donc lorsque vous allez créer les différents attributs qui composeront vos futurs classes de contenu, ils se verront attribuer un identifiant unique. Pour le moment je ne suis pas suffisamment expérimenté dans ce domaine pour vous apporter plus de précisions, mais sachez qu’il est tout a fait possible de créer vos propres datatypes (en PHP). Ce qui montre bien une fois encore que vous pourrez réellement faire ce que vous voulez avec eZ Publish.
Pour les rubriques et les pages, le raisonnement reste identique en tout point, une classe de contenu pourra être utilisée dans un ou plusieurs nœuds. Il n’y a en théorie aucune limite, vous avez la possibilité d’en créer autant que nécessaire, sans même vous soucier de l’impact que cela pourrait avoir sur votre site et sa gestion … si ce n’est son ergonomie, mais là c’est une autre histoire!
eZ Publish : premières impressions
Voilà plus de deux mois que j’utilise eZ Publish pour les projets qui me sont confiés chez Metycea et je n’ai pas résisté à l’envie de partager mes premières impressions. Pour plus d’informations sur l’outil, n’hésitez pas à consulter le site officiel de l’éditeur : http://ez.no/fr/
Une première approche
Le CMS peut paraître relativement indigeste pour un grand nombre de développeurs non-avertis, tout simplement parce qu’eZ Publish c’est avant tout des centaines de fichiers et de dossiers… très bien organisés! Rassurez-vous, avec le temps on fini par s’y retrouver très facilement, d’autant plus que lors d’un développement lambda, vous passerez près de 90% de votre temps dans ces deux répertoires :
- design: contient ce qui touche de près comme de loin à l’élaboration de vos pages (html, css, js, images etc…) ;
- settings: fichiers de configurations (.ini).
Il faut savoir qu’eZ Publish fonctionne en Modèle-Vue-Contrôleur, où toutes les vues seront des templates facilement personnalisables à l’aide de surcharges (selon les cas) définies dans un fichier de configuration bien spécifique. Notez que cette logique s’applique aussi-bien en front qu’en backend.
Sous eZ Publish, tout est objet
La force du CMS réside dans sa conception même. Admettons que vous souhaitez créer un template de page simple qui comporte un titre principal, une description courte et un corps.
Pour commencer, il suffira de vous rendre dans le manager et d’y créer une classe de contenu nommée « page » (son type) composée des attributs cités précédemment (name, description, body) eux aussi typés (ligne de texte, bloc de texte, éditeur wysiwyg). On remarque une forte analogie avec le modèle objet des langages de programmation, c’est normal puisqu’il s’agit réellement d’une classe comme vous avez très certainement l’habitude d’en créer en PHP ou en JAVA. Ensuite, lors de l’intégration, il faudra simplement créer un fichier page.tpl (dossier design) qui réalise les différents traitements (à l’aide de templates operators) pour l’affichage de nos différents éléments (les attributs cités plus haut). Pour terminer, vous aurez besoin d’indiquer à la plateforme quel template utiliser pour les objets de type « page », le tout dans d’un fichier de configuration nommé overrides.append.ini.php (dossier settings). La procédure restera identique pour toutes les classes de contenu que vous aurez besoin de créer par la suite.
En résumé: Création de la classe de contenu » Intégration (template) » Ajout de la classe dans les settings.
Une histoire de cache !
Sous eZ Publish, vous vous apercevrez très vite que tout est fait pour optimiser votre temps de développement, mais en contre-partie, votre site pourra parfois afficher des délais de réponses trop élevés pour internet. Pour pallier à ce manque de réactivité, et en vue du grand nombre de fichiers de configuration et de templates que vous aurez besoin de créer pour vos futurs projets, eZ Publish va tout mettre en cache … ou presque. La conséquence d’un tel comportement ? Un temps de réponse optimal avec des pages qui s’affichent très rapidement (sauf au premier chargement des vues qui seront alors mises en cache). Du peu que j’ai pu constater, le framework va stocker certaines de vos règles de configuration (les fichiers ini), vos templates et les différentes références de vos images, des tailles pré-définies susceptibles d’être utilisées en front et/ou backend.
L’aide au développement
Pour vous accompagner dans vos différentes phases de développement, eZ Publish propose un mode de débogage qui vous permettra entre autres de dépister les petites comme les plus grosses erreurs. Cet outil s’avère très pratique lorsque le résultat d’un traitement n’est pas celui escompté en vous indiquant précisément l’origine de l’erreur. En plus de ça, il affiche le nom des templates utilisés pour vos pages, et pour ma part, c’est ce qui rend son utilisation incontournable. En effet, lorsqu’on débute (et même des semaines plus tard), on ne connait pas toujours le chemin complet des templates standards à surcharger pour nos besoins, grâce à cette aide, fini les longues minutes de recherche dans le répertoire des templates par défauts.
En conclusion
Avec le recul, on s’aperçoit vite qu’eZ Publish a tout ce qu’il vous faut pour mettre en place des sites administrables robustes et sécurisés. De base, il propose une large palette de classes de contenu modifiables à souhait. Bien entendu, comme nous venons de le voir, il est aussi possible d’en créer autant que vous le souhaitez en ne partant de rien. Il n’est pas nécessaire d’avoir de très lourdes connaissances en PHP, en effet, avec eZ Publish vous devrez vous familiariser avec les templates operators qui permettent de récupérer les informations d’un objet à afficher lors du développement de vos templates (titre d’une page, son contenu riche etc…). En revanche, si vous souhaitez développer des extensions, il faudra mettre les mains dans le cambouis. Fort heureusement, rien d’insurmontable et le site officiel propose de nombreux tutoriaux qui vous permettront d’arriver à vos fins.
Il faudra faire avec le cache, ne pas oublier de le désactiver lors de vos développements et surtout le vider régulièrement, sans oublier d’utiliser le mode de débogage et ainsi vous faire gagner un temps précieux.
Pour ma part, à l’heure où je rédige cet article je suis en plein dans mon 4me projet sous eZ Publish, je me rend compte sans grande surprise qu’il n’y a vraiment pas de limites. eZ Publish est développé de tel sorte que vous pourrez réellement faire de l’outil ce que vous en voulez!
Quelques liens utiles :
Upload avec barre de progression sous Flex
Pour cet article, je me suis efforcé d’aller à l’essentiel afin d’éviter tout traitement superflue qui irait à l’encontre d’une compréhension rapide et optimale. Il s’adresse donc a des développeurs qui ont une certaine maîtrise du langage mais qui ne savent pas réellement comment mettre ne place un tel système de transfert de fichier.
1. L’interface
L’interface se compose uniquement de deux éléments:
- Un bouton ‘Parcourir…’ qui va nous permettre d’aller récupérer notre fichier ;
- Une barre de progression, qui s’affichera au lancement de l’upload.
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="init();">
<mx:Script>
<![CDATA[
import aruiz.CUpload;
private function init ():void {
new CUpload (browseButton, progressBar);
} // init ();
]]>
</mx:Script>
<mx:Button id="browseButton" label="Parcourir..."></mx:Button>
<mx:ProgressBar id="progressBar" label="" visible="false"></mx:ProgressBar>
</mx:Application>
Comme vous pouvez le constater, l’interface a été volontairement réduite au strict minimum. Pour notre upload, nous utiliserons la classe CUpload qui attend deux paramètres: le bouton ‘Parcourir…’ et la barre de progression (ID des éléments concernés).
2. La classe CUpload
Voici la signature de type des différentes méthodes de la classe:
- private function initListeners ():void;
- public function browse (e:MouseEvent):void;
- private function selectHandler (e:Event):void;
- private function errorHandler (e:IOErrorEvent):void;
- private function progressHandler (e:ProgressEvent):void;
- private function completeHandler (e:Event):void;
La plus importante est initListeners, elle va se charger comme son nom l’indique, d’initialiser tous les écouteurs d’événements. Dans ce cas précis on parle de programmation événementielle. Tout simplement parce que lors d’un upload, il y a différentes phases qu’il est important de prendre en considérations, sans quoi il serait totalement impossible de lier toutes les actions entre-elles.
- browse est appelée lors du click sur le bouton ‘Parcourir…’, elle a en charge d’ouvrir une fenêtre qui va permettre aux utilisateurs de choisir un fichier à transférer ;
- selectHandler est appelée lorsqu’un fichier a été choisi par l’utilisateur, l’upload peut alors commencer ;
- errorHandler parle d’elle même, nous ne sommes pas à l’abri d’une erreur, il faut pouvoir la capturer pour stopper tout traitement et en avertir l’utilisateur ;
- progressHandler va nous permettre de connaître l’avancement du transfert. Comment ? A l’aide du paramètre ‘e’ de type ProgressEvent qui contient toutes les informations nécessaires. Ainsi notre barre de progression sera mise à jour de la sorte: progressBar.setProgress (e.bytesLoaded, e.bytesTotal);
- completeHandler sera appelée en fin d’upload si tout s’est correctement déroulé.
3. Coté serveur (PHP)
Les traitements sont identiques à ceux d’un upload classique en HTML/PHP. En effet, il suffit juste d’utiliser la variable globale $_FILES (un tableau associatif) qui contient toutes les informations relatifs à notre upload. Là aussi, le code source a été volontairement simplifié pour aller à l’essentiel. Gardez en tête qu’un upload quel qu’il soit reste sensible d’un point de vu de la sécurité, il faudra donc réaliser une batterie de test afin d’être sûr que les fichiers répondent bien à certains critères, notamment leur type.
Le script est appelé en fin d’upload lorsque tout a été entièrement transféré sur le serveur. Si un ajout en base ou l’envoi d’un email est nécessaire, c’est à ce niveau du code qu’il faudra ajouter des fonctionnalités supplémentaires. Inutile donc de faire appel à un script PHP supplémentaire depuis la méthode completeHandler.
4. Conclusion
Cet article n’a rien de bien extraordinaire tellement l’upload a été vu et revu sur de nombreux blogs à travers le web. Cependant, j’ai reçu une demande d’aide de la part d’un internaute, et c’est ce qui a motivé ce court développement. Le point fort de Flex, est qu’il permet de filtrer avant tout upload les types de fichiers autorisés, cela dit, rien n’empêche de cacher du code malveillant (PHP) dans une image … Durant la phase de test, j’ai noté que les fichiers de plus de 2MO n’étaient pas transférés. C’est tout à fait normal, si c’est votre cas, il va falloir changer certaines règles de configuration (php.ini).
Si vous avez des questions, le blog est fait pour ça 