Mémoire licence création d’un site web d’etransparence avec des technologies libres, tutoriel & guide de travaux pratiques en pdf.

Apache Cocoon

Définition

Cocoon est un framework permettant de réaliser des applications Web (applications s’exécutant sur un navigateur Web) flexibles et sophistiquées sur base des langages XML et Java.
Un framework est un ensemble de bibliothèques et d’outils qui permettent un développement plus rapide d’une application, du fait que beaucoup de choses ont déjà été implémentées. Ces composants sont organisés pour être en interaction les uns avec les autres et pour fonctionner comme un tout.
Cocoon est un projet Open Source de l’Apache Software Foundation (ASF). Ses principaux atouts sont la publication des pages en de multiples formats et la séparation des tâches.

Technologies
Le coeur de Cocoon est entièrement codé en Java. Cependant, pour développer des applications avec Cocoon, aucune programmation n’est nécessaire, tout se décrit dans des fichiers XML.
Cocoon est une servlet qui nécessite un serveur d’applications pour fonctionner. Nous avons choisi Tomcat pour assurer ce rôle. Il existe néanmoins d’autre serveurs d’applications tout aussi performants, par exemple Jetty.

Concepts
Formats multiples
Cocoon a pour but de changer l’organisation et la publication de l’information sur le Web. En effet, il facilite la mise à disposition de l’information sous de multiples formats et plate-formes.
Les données sources de l’information peuvent être de natures multiples telles que des fichiers textes, des fichiers XML (surtout), des bases de données, etc. Il suffit de modifier le module de présentation pour modifier l’apparence ou le format de rendu final (HTML, WML, TXT, PDF, ZIP, JPEG, SWF, etc.).
Cette fonctionnalité est réellement pratique lorsque des données doivent être mises à disposition des clients sous différents formats. Cocoon permet donc de publier rapidement des sites multi-supports et résout de manière simple les problèmes d’incompatibilité entre navigateurs.
Séparation des tâches
Le concept de séparation des tâches (Separation of Concerns en anglais) permet de distinguer les différents « métiers » que l’on retrouve dans un cycle de publication d’informations sur le Web.
Il est composé de quatre contextes de travail différent :
• Gestion du site : décisions sur le contenu, le comportement et l’apparence du site.
• Contenu : écriture et gestion du contenu du site.
• Style : présentation de l’information, aspect et apparence graphique du site.
• Logique : intégration avec les technologies de génération de contenu dynamique et les systèmes de base de données.
Cette séparation permet à chaque couche d’être conçue, créée et gérée indépendamment. Cela permet une meilleure gestion des ressources humaines, en fournissant à chaque individu son travail et en réduisant au minimum les discussions croisées entre différents contextes de travail.
La séparation des tâches de Cocoon est une implémentation de l’architecture MVC. MVC (Model-View-Control) est un patron de conception (design pattern en anglais) pour le développement d’applications logicielles qui sépare le modèle de données, l’interface utilisateur et la logique de contrôle. Cocoon n’implémente pas « à la lettre » l’architecture MVC. C’est pour cela qu’on parle parfois de MVC+ lorsque l’on parle de la séparation des tâches dans Cocoon.

Les deux faces de Cocoon
Cocoon propose deux aspects différents : l’aspect utilisateur et l’aspect développeur.
L’aspect utilisateur est ce que nous allons étudier dans ce mémoire, il s’agit de créer des applications Web avec les possibilités (nombreuses) offertes par Cocoon. L’utilisateur de Cocoon n’a besoin que de connaître le XML (et ses dialectes) comme prérequis. En effet, pour créer un application avec Cocoon, il suffit de déclarer les composants que l’on utilise dans un fichier XML (voir Chapitre 3, Section 6.1, “Sitemap”). C’est d’ailleurs pour cette raison qu’on dit que Cocoon est déclaratif1.
1 Par opposition, par exemple, aux paradigmes tels que le procédural, l’orienté objet ou le fonctionnel.
L’aspect développeur permet à celui s’en sentant capable ou en ressentant le besoin de modifier ou d’étendre les fonctionnalités de Cocoon. Ceci est rendu possible par le fait que Cocoon est totalement Open Source. Étant donné que Cocoon est développé entièrement en Java, la connaissance de ce langage est requise pour pouvoir se lancer dans le développement de nouveaux composants. Cet aspect ne sera pas étudié dans ce mémoire.

Historique
Stefano Mazzocchi
Cet informaticien italien, membre du groupe Apache, est le fondateur du framework Cocoon. C’est en 1998, à l’age de 23 ans, alors qu’il n’était à l’époque que stagiaire chez Apache, qu’il a eu l’idée de créer un système permettant de séparer les tâches et d’automatiser la production de pages Web.
Cocoon 1
Le projet Cocoon a donc été initié en Janvier 1999 par Stefano Mazzocchi. Cette première mouture de Cocoon, qui ne comptait qu’une centaine de lignes de code, servait uniquement à transformer du XML avec l’aide de l’API DOM (Document Object Model). L’utilisation de cette API d’accès aux données a vite montré ses limites. En effet, elle entraînait des problèmes de vitesse et une utilisation peu rationnelle de la mémoire.
Cocoon 2
Le développement de Cocoon 2 a commencé en parallèle à celui de Cocoon 1. Cocoon 2 a ainsi vu le jour en Novembre 2001. Il apporte de nombreuses améliorations et corrige notamment les problèmes de vitesse et d’utilisation mémoire.
L’utilisation de l’API SAX (Simple API for XML Parsing) pour accéder aux données XML permet de travailler avec de gros fichiers XML sans pénaliser les performances.
Parmi les améliorations techniques il faut particulièrement retenir les fonctions de pré-compilation et de mises en caches qui ont été introduites dans cette version. Pour simplifier l’utilisation de Cocoon, les fonctions de management ont été revues et centralisées. Cocoon est depuis sa version 2 parfaitement adapté à une utilisation en production.

CHAPITRE 1. INTRODUCTION
1. PRESENTATION DU MEMOIRE
2. STRUCTURE DU MEMOIRE
2.1. Chapitre 2
2.2. Chapitre 3
2.3. Chapitre 4
2.4. Chapitre 5
2.5. Chapitre 6
2.6. Chapitre 7
2.7. Chapitre 8
3. ACRONYMES ET ABREVIATIONS
CHAPITRE 2. TECHNOLOGIES UTILISEES
1. PREREQUIS
2. TECHNOLOGIES ABANDONNEES
2.1. Xindice
2.2. eXist
2.3. Struts
2.4. Lenya
2.5. Forrest
3. TECHNOLOGIES UTILISEES
3.1. Tomcat
3.2. RSS
3.3. Wiki
CHAPITRE 3. APACHE COCOON
1. DEFINITION
2. TECHNOLOGIES
3. CONCEPTS
3.1. Formats multiples
3.2. Séparation des tâches
3.3. Les deux faces de Cocoon
4. HISTORIQUE
4.1. Stefano Mazzocchi
4.2. Cocoon 1
4.3. Cocoon 2
5. INSTALLATION
6. ARCHITECTURE
6.1. Sitemap
6.2. Pipelines
6.3. Les composants
6.4. Récapitulatif de l’exécution d’une requête
6.5. Autres concepts
CHAPITRE 4. COCOON COMPARE A PHP
1. COMPARAISON
1.1. Prix
1.2. Documentation
1.3. Hébergement
1.4. Facilité d’installation
1.5. Facilité d’utilisation
1.6. Liaison avec les bases de données
1.7. Séparation des tâches
1.8. Maintenance et réutilisabilité
2. CONCLUSION
CHAPITRE 5. EXEMPLE RECAPITULATIF AVEC COCOON
1. MISE EN SITUATION
2. REPERTOIRES ET CANEVAS DE FICHIERS
3. AFFICHAGE D’UNE PAGE HTML
4. AFFICHAGE D’UNE PAGE PDF
5. AFFICHAGE D’UNE PAGE XML
6. INTERNATIONALISATION (I18N)
7. REPERTOIRE MUSICAL
8. STATISTIQUES
CHAPITRE 6. POLITIQUE ADOPTEE SUR LE SITE D’ETRANSPARENCE
1. MISE EN SITUATION
2. RESPECT DES NORMES
3. DESIGN « TABLELESS »
3.1. Introduction
3.2. Positionnement CSS
3.3. Problèmes des tableaux
4. COMPATIBILITÉ
5. REFERENCEMENT
CHAPITRE 7. ANALYSE FONCTIONNELLE DU SITE D’ETRANSPARENCE
1. MISE EN SITUATION
2. TACHES A ACCOMPLIR
2.1. Partie commerciale
2.2. Vente de matériel
2.3. Partie scientifique
2.4. Système de news
2.5. Formulaire de contact
2.6. Moteur de recherche interne
2.7. Espace administrateur
2.8. Espace client
2.9. Version PDA
2.10. Version WAP
CHAPITRE 8. IMPLEMENTATION DU SITE D’ETRANSPARENCE
1. STRUCTURE GENERALE DU SITE
1.1. Arborescence de fichiers
1.2. Structure d’une page
1.3. Plan du site
2. FONCTIONNALITES
2.1. Système de news (RSS)
2.2. Zone téléchargements
2.3. Moteur de recherche interne
2.4. Vente de matériel
2.5. Formulaire de contact
2.6. Version WAP
2.7. Version PDA
3. TRAVAUX FUTURS
3.1. Espace administrateur
3.2. Espace client
3.3. Partie scientifique
3.4. Et après?
CHAPITRE 9. CONCLUSION GENERALE
BIBLIOGRAPHIE