La recherche internet repensée… - univ-rennes1.fr · Enfin, le choix de la technologie WPF pou p...

Projet « Nactus » Jeudi 20 mars 2008 IUT de Lannion 2007-2008

1

NACTUS La recherche internet repensée…

Etudiants :

Raphaël HAMON ([email protected])

Raynald BRIAND ([email protected])

Damien GUEZOU ([email protected])

Steven HERNIO ([email protected])

Kévin LE QUELLENEC ([email protected])

Christophe LAVALLE ([email protected])

mailto:[email protected]







2

Sommaire

Sommaire ................................................................................................................................................ 2

Introduction ............................................................................................................................................. 4

I. Présentation du sujet : .................................................................................................................... 5

1) Explication détaillée : .................................................................................................................. 5

2) Choix du nom du projet : ............................................................................................................. 5

3) Langage de programmation : ...................................................................................................... 6

4) Concept :...................................................................................................................................... 7

II. Planification - tâches : ..................................................................................................................... 8

1) GANTT : ........................................................................................................................................ 8

2) Descriptif des tâches : ............................................................................................................... 12

III. Module « Gecko » : ................................................................................................................... 14

1) Analyse : .................................................................................................................................... 14

2) Développement : ....................................................................................................................... 15

IV. Module « Recherche » :............................................................................................................. 17

1) Analyse : .................................................................................................................................... 17

2) Développement : ....................................................................................................................... 19

3) Description du filtrage ............................................................................................................... 20

V. Module « Affichage 3D » : ............................................................................................................. 22

1) Analyse : .................................................................................................................................... 22

2) Développement : ....................................................................................................................... 23

VI. Module « barre de navigation » : .............................................................................................. 27

1) Analyse : .................................................................................................................................... 27

2) Développement : ....................................................................................................................... 29

VII. Module « favoris » : ................................................................................................................... 32

1) Analyse : .................................................................................................................................... 32

2) Développement : ....................................................................................................................... 34

VIII. Module « historique » : ............................................................................................................. 35

1) Analyse : .................................................................................................................................... 35


3

2) Développement : ....................................................................................................................... 36

IX. Conclusion ................................................................................................................................. 38

X. Annexe ........................................................................................................................................... 39

1) Exemple complet : ..................................................................................................................... 39

2) Description des classes : ............................................................................................................ 43

a. Module « Gecko » : ............................................................................................................... 43

b. Module « Génération des aperçus » : ................................................................................... 45

c. Module « Recherche » :......................................................................................................... 46

d. Module « Affichage 3D » : ..................................................................................................... 48

e. Module « barre de navigation » : .......................................................................................... 50

f. Module « favoris » : ............................................................................................................... 51

g. Module « historique » : ......................................................................................................... 54


4

Introduction

Dans le cadre du projet de seconde année Informatique à l’IUT de Lannion, nous avons choisi

de réaliser un navigateur Internet. Celui-ci a pour but d’améliorer les points suivant par rapport à ce

qui existe actuellement :

Les résultats d’une recherche sur un moteur de recherche (exemple : Google) seront

présentés sous forme visuelle, organisée en 3D.

La présentation visuelle des sites sera privilégiée pour naviguer dans l’historique ou

les favoris de l’utilisateur.

Ce dossier regroupe les phases d’analyses et de développement qui ont permis la réalisation

du projet.


5

I. Présentation du sujet :

1) Explication détaillée :

Les résultats d’une recherche (mots clés saisis par l’utilisateur) seront d’abord récupérés puis

enregistrés.

Un « aperçus » de chaque site devra être créé à l’aide d’un moteur de rendu (Gecko).

Ces résultats seront présentés de manière ergonomique sous forme de Flow (type Cover

Flow d’ Apple). Lorsque l’utilisateur avance dans la prévisualisation des résultats, les «aperçus»

seront pré-chargés en mémoire pour une navigation fluide. La circulation des résultats à l’écran se

fera à l’aide de la roulette de la souris, avec les flèches de direction du clavier ou en cliquant sur les

boutons : suivant/précédent. L’interface utilisée n’est pas une interface web mais un composant

développé dans le langage choisi.

2) Choix du nom du projet :

Concernant le nom du projet, nous avions tout d’abord pensé à un moyen de mettre en

évidence la présentation visuel des sites. Cependant cette idée fut abandonnée car les propositions

étaient trop explicites. Nous nous sommes ensuite orientés vers une autre langue, très vite est

apparu l'idée du latin. Aucun de nous ne connaissant cette langue il a été décidé de consulter un

dictionnaire en ligne et le mot « Nactus » a été trouvé. Sa définition est la suivante :

« Nactus »

1 - qui a rencontré, qui a trouvé, qui a acquis, qui a reçu, qui a gagné.

2 - sens passif : acquis, trouvé.

Après discussion, ce nom fut retenu.


6

3) Langage de programmation :

L’environnement de développement Visual Studio 2008 .NET 3.5 fut choisi, avec le langage

de programmation C# et WPF (Windows Presentation Foundation) pour l’interface.

Les raisons ayant motivant notre choix sont tout d’abord la qualité de l’environnement de

développement Visual Studio. Celui-ci est de plus en plus utilisé dans le monde professionnel. A

défaut de l’utiliser en cours, nous trouvons que c’est une bonne opportunité d’étendre nos

connaissances sur un produit que nous seront certainement amené à réutiliser dès le stage en

entreprise pour certains d’entre nous.

De plus, il existe une grande communauté d’utilisateur autour de ce produit et de ces

différents langages. Cela nous a permis de trouver facilement des réponses à nos questions ainsi que

de posséder une source de documentation très importante.

Enfin, le choix de la technologie WPF pour programmer l’interface est un choix tourné vers

l’avenir. En effet, ce type d’interface va avoir tendance à se généraliser dans le futur et est appelé à

remplacer les interfaces Win32 que connues actuellement. La technologie WPF permet de décrire

l’interface de l’application via un langage XAML basé sur le langage XML. Celui-ci permet de faire des

choses basiques comme complexe (3D, espace vectorielle…).

Pour conclure, nous utiliserons des technologies de pointes tournées vers l’avenir pour un

navigateur à la pointe.


7

4) Concept :

Voici un concept d’interface dynamique :

L’utilisateur peut cliquer sur un des clichés présentés, il rentre alors en mode de navigation

sur le site choisi avec les divers outils basiques de navigation : retour en arrière, en avant, rafraichir la

page…

Les options développées pourront évoluer au cours du projet suivant son avancement.


8

II. Planification - tâches :

1) GANTT :


9


10

Après avoir réalisé le projet, certains délais ont été suffisant pour la réalisation de certaines

tâches tandis que d’autres ce sont révélés être incorrects par rapport à ce qui avait été prévu.

Nous pouvons expliquer ces changements par plusieurs choses. L’apprentissage du langage

de programmation et de l’outil utilisé na pas été le même pour tous le monde. De plus, des difficultés

techniques sur certains points sont apparues suivant le niveau de chacun. Enfin, durant le

développement de certaines tâches, le code a du être repris pour permettre de pouvoir assembler et

implémenter les parties. La cohérence du projet était en jeu.

Ces différents changements ont conduis aux GANTT suivant :


11


12

2) Descriptif des tâches :

1. Interprétation (GECKO) :

Wrappers (via ActiveX : objet COM)

Gestion des plugins : flash player, java, vidéos players

2. Barre de navigation (GECKO) :

Accéder à la page précédente/suivante

Actualiser une page/arrêter un chargement/démarrer un chargement

Barre d’adresse

3. Navigation :

Navigation par onglets

Accès aux favoris/historiques

Prévisualisation des l’ensemble des onglets ouvert

4. Recherche :

Récupération des résultats (Google)

Faire une sauvegarde virtuelle des recherches

Extension de la recherche aux autres moteurs

Recherche de page similaire à une page issue d’une page

5. Affichage 3D :

Génération de maquette

Présentation 3D

Navigation entre les maquettes

Zoom sur une maquette

Ouverture du site

6. Favoris :

Exporter les favoris

Importer les favoris

Suppression/ajout

Organiser les favoris

Vérification de doublons


13

7. Historique :

Suppression/ajout

Organiser l’historique

Vérification de doublons

Légende :

Au cours du projet, la liste des tâches réellement réalisées a évolué. Quelques fonctionnalités

ont dut être abandonnées par manque de temps. Cependant, l’ensemble des tâches obligatoires ont

été réalisées à l’exception de quelques une comme le zoom sur un aperçu d’un résultat d’une

recherche ou des fonctions pour l’organisation des favoris.

Voici la liste des tâches réellement effectuées :

1. Interprétation (GECKO) : Wrappers (via ActiveX : objet COM)

Gestion des plugins : flash player, java, vidéos players

2. Barre de navigation (GECKO) :

Accéder à la page précédente/suivante

Actualiser une page/arrêter un chargement/démarrer un chargement

Barre d’adresse

3. Navigation : Navigation par onglets

Accès aux favoris/historiques

4. Recherche : Récupération des résultats (Google)

5. Affichage 3D :

Génération de maquette

Présentation 3D

Navigation entre les maquettes

Ouverture du site

6. Favoris :

Exporter les favoris

Importer les favoris

Suppression/ajout

7. Historique : Suppression/ajout

Organiser l’historique


14

III. Module « Gecko » :

1) Analyse :

Il y a plusieurs intérêts à l’utilisation d’un wrapper. Tout d’abord, celui-ci nous

permet d’utiliser un moteur de rendu externe à notre projet, en l’occurrence Gecko développé par la

Fondation Mozilla et notamment utilisé dans Firefox.

Cela nous permet aussi de réduire le temps de développement car un moteur de rendu est

complexe et long à développer. Nous n’aurions pas pu en développer un qui soit capable d’afficher la

majorité des sites Internet à l’heure d’aujourd’hui.

Pour finir, un wrapper ActiveX de type objet COM s’intègre parfaitement dans

l’environnement de développement Visual Studio.

Nous utiliserons la dernière version publiée par la Fondation Mozilla, c'est-à-dire à la version

1.9. Celle-ci se trouve encore en version bêta. D’ici la fin du projet, nous aurons la version finale de

celle-ci. Son stade de développement nous permet déjà de l’utiliser car ces spécificités ont été

clôturées. Une certaine stabilité est déjà présente.

La distribution de ce wrapper s’effectue via la distribution du package XUL Runner. Celui-ci

intègre le moteur de rendu ainsi qu’une technologie de description d’interface en XML mappable à

l’aide du moteur de rendu Gecko. Il suffit de déclarer la dll en gestion du wrapper au sein du système

pour pouvoir l’utiliser. Ce package de XULRunner sera donc intégré dans le projet et installé sur le

système lors de l’installation de notre navigateur sans que nous utilisions la technologie de mappage

d’interface en XML.

Nous avons envisagé de créer directement notre wrapper à partir du code source en C/C++

de Gecko publié par Mozilla. Cependant, celui-ci était compliqué à comprendre. Le temps passé pour

le mettre en œuvre n’aurait pas été en accord avec le temps prévu pour le projet.

Voici un schéma expliquant l’implémentation et la position du wrapper de Gecko avec notre

projet :


15

2) Développement :

Implémentation de Gecko :

Ce module devait consister au développement d’un wrapper en C++ natif permettant

d’inclure le moteur de rendu Gecko au sein de l’application. Cette méthode a posé divers problèmes.

La complexité du code de Gecko ne permettait pas une bonne compréhension. Des

problèmes de compilation existaient également. La présence de nombreux « callback » sur lesquels

des méthodes devaient être connectées afin de faire interagir le moteur de rendu avec l’application

était aussi légèrement flou et compliqués. Du moins, nous ne possédions pas un bagage de

connaissance assez important pour comprendre ce mécanisme dans un laps de temps relativement

court afin de ne pas compromettre la réalisation du projet. La mise en place du moteur de rendu

Gecko est en effet un élément essentiel.

Le problème a été résolu en utilisant le wrapper C++ natif de Gecko fourni par Mozilla. Ce

dernier est programmé pour être inclus au sein de l’application sous le format d’un ActiveX

enregistré au sein du système comme objet COM. Une méthode banale que de nombreux logiciels

utilisent tous les jours.

La conséquence de l’utilisation de cet objet COM est la modification de l’installeur de

l’application qui doit prendre en compte le fait de devoir enregistrer cet objet COM dans le système

lors de l’installation de Nactus.

La deuxième conséquence est la lourdeur que provoque cette solution. N’étant pas native,

elle demande un petit temps de chargement qui est accentué par l’utilisation de la technologie WPF

pour l’interface de l’application. Ce point précis pourra être amélioré dans une mise à jour de Nactus.

L’objet COM utilisé ce trouve dans la bibliothèque dynamique mozctlx.dll distribué par

Mozilla. Cette librairie fait partie d’un ensemble de librairies disponibles sous le nom XULRunner. Le

moteur de rendu de Gecko est présent dans ces nombreuses librairies. Nous avons décidé d’utiliser la

dernière version de Gecko : la 1.9. Celle-ci est en cours de développement par Mozilla. Cependant,

elle va prochainement passée en version Release Candidate qui permet de mettre un certain niveau

de qualité sur son code. De plus, cela nous permet d’avoir un rendu optimisé des pages web.

Lien de téléchargement :

ftp://ftp.mozilla.org/pub/xulrunner/nightly/latest-trunk/

ftp://ftp.mozilla.org/pub/xulrunner/nightly/latest-trunk/


16

Implémentation de la génération d’aperçus :

L’implémentation de Gecko au sein de l’application n’a pas été le seul travail effectué au sein

de cette partie. Il y a eu la création d’une classe permettant de générer dynamiquement le rendu

d’une page web sans l’afficher dans notre application.

Cette classe se base sur le chargement de la page web au sein d’un composant Gecko non

visible dans l’application. Ce composant est donc chargé dans la mémoire vive de l’ordinateur.

Lorsque la page est chargée, un évènement est déclenché. Cela provoque la prise d’un cliché

instantané de la surface du composant créé en mémoire. Ce cliché est ensuite encodé sous la forme

d’un objet image WPF. Une nouvelle image peut alors être générée.

Cette méthode qui a été choisie pour générer les aperçus des sites web ne consomme pas

plus de ressource hormis celle consommée par une page web standard qui s’affiche au sein de

l’application.


17

IV. Module « Recherche » :

1) Analyse :

Le module de recherche est une partie importante du navigateur. Il s’agit ici de pouvoir

récupérer un ensemble de site internet suite à une requête effectuée par l’utilisateur. Le principe

consiste en l’utilisation des résultats que génèrent les moteurs de recherches comme Google, Yahoo!

ou Windows Live Search.

Pour interroger les différents moteurs de recherche présents sur Internet, nous utiliserons des Web Services. Ceux-ci sont directement développés et fournis par les moteurs de recherche eux même. Un Web Service est une interface utilisable dans n’importe qu’elle langage de

programmation. Il suffit pour cela de configurer notre module Web Service dans Visual Studio pour

avoir accès à une liste de méthode disponible pour interroger le moteur de recherche et manipuler

les résultats retournés. Cette méthode d’interrogation nous permet de garantir la conformité des

données même après une mise à jour de l’interface ou du « moteur » du moteur de recherche. Cela

nous permet également d’avoir des résultats génériques et non transformés dans le but d’une

utilisation spécifique dans le but d’éviter de devoir traiter une première fois les données avant de les

rendre utilisables au sein de notre navigateur. Nous pouvons modéliser les échanges avec le schéma

ci-dessous :


18

Ce schéma montre le déroulement d’une recherche. Premièrement, l’utilisateur écrit sa

requête, celle-ci est envoyer au web service via des méthodes spécifiques. La requête est ensuite

étudié par le moteur de recherche qui nous renvoi les résultats correspond sous un format définit

par le Web Service. Pour utiliser ce format, il suffit d’utiliser les méthodes données par le Web

Service et qui sont prévues à cet effet.

Il va donc y avoir un traitement qui va consister à stocker les informations reçues dans un

fichier XML. Nous avons choisi ce format car c’est le format de stockage d’informations actuellement

utilisé sur Internet. De plus, il permet d’avoir une certaines rétrocompatibilité avec d’autres services

ou applications. Voici le fichier XSD qui défini la structure de stockage des informations dans le fichier

XML :

<?xml version="1.0" encoding="UTF-8" ?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="resultSearch">

<xs:complexType>

<xs:sequence>

<xs:element name="url" type="xs:anyURI" use="required"/>

<xs:element name="titre" type="xs:String" use="required"/>

<xs:element name="descriptif" type="xs:String"

use="required"/>

<restriction base='String'>

<maxLength value='200'/>

</restriction>

</xs:sequence>

<xs:attribute name="id" type="xs:long" use="required"/>

</xs:complexType>

</xs:element>

</xs:schema>

Comme le schéma le décrit, nous stockerons l’url, le titre et le descriptif qui nous sera

retourné pour chaque résultat d’une recherche. De plus, nous stockerons la position du résultat au

sein des résultats de la recherche dans le champ « id » qui sera également défini comme une clé.

Nous imposons également une restriction au niveau de la taille maximum d’un titre et d’une

description à un nombre maximum de 200 caractères. Nous avons remarqué que les plus grand titre

ou description ne dépassées pas les 160 caractères. Les formats de données choisis sont explicités

dans le schéma XSD.

Ce schéma XSD nous permet d’avoir une vue globale concernant la manière dont est stocké

l’information mais également de pouvoir par la suite vérifier la validité des fichiers XML générés.


19

2) Développement :

Suite à l’analyse éffectuée, le module Recherche devait utiliser les web services de google

pour récupérer les résultats d’une recherche directement sous forme xml. Malheureusement au

début de la phase de codage, google a fermé ce service et ne délivrait plus de clé de connexion. Suite

à ce problème, restait maintenant à chercher une nouvelle méthode pour récupérer les résultats.

Après réflexion, la meilleure solution trouvée est de récupérer le code source généré par

google lors d’une recherche. La récupération de ce code s’effectue dans le constructeur de la classe

Recherche. On interroge le serveur de google et après lecture des données reçues, on écrit

simplement dans un fichier texte le code source générée.

Une exception est levée lors de la création d’une nouvelle recherche lorsque l’utilisateur

n’est pas connecté à internet. Dans ce cas le fichier texte contient un message d’information relatant

l’erreur.

Maintenant que les résultats sont récupérés, il faut « filtrer » le fichier texte afin d’en

ressortir les informations souhaitées. Un fichier XML est créé dans la méthode CreationXml(), il sera

complété par les différents sites récupérés.

Avant de commencer on vérifie que la recherche nous retourne au moins un résultat. Pour

connaitre le nombre total de résultats que google a trouvé, une méthode nombre_resultats() permet

de filtrer le code source et de récuperer le nombre de résultats. Si ce nombre est nul, le fichier XML

contient un message d’information expliquant l’absence de résultat, sinon le fichier est traité.

Le filtrage consiste en la lecture caractère par caractère du texte. Ce dernier est inséré dans

un tableau que l’on parcourt jusqu’au dernier élément. L’étude du code source a permis de créer un

diagramme d’état, dont chaque étape correspond en la récupération des données d’un Site (voir

shémas et explication ci-dessous).

La phase de filtrage est appelée autant de fois que de nombre de site récupéré lors de l’appel

d’une recherche. Trois variables sont initialements déclarées, une pour l’URL, une pour le titre et une

pour la description. Lors du passage dans le filtre, on écrit dans celles-ci les données analysées.

Ensuite on complète le fichier XML en y écrivant chacune des variables. A la fin du traitement du

fichier source celui-ci est automatiquement supprimé.

Au début, lors de différents tests, plusieurs problèmes sont apparus. Pour certains mots on

obtenait des résultats composés de sites habituels et un ou plusieurs résultats de type actualité. Ces

sites ne passaient pas dans le filtre car ils ne correspondent pas au résultat google habituel, c'est-à-

dire composés d’une url, d’un titre et d’une description. Nous avons décidé de ne pas tenir compte

de ce type de résultat et de ne pas les traiter. D’autres résultats ont posé problèmes, certains sont en

anglais mais jugeant nécessaire d’intégrer ces résultats, nous avons modifié le filtrage afin de les

intégrer.

Les tests d’affichages ont montré que l’encodage du texte ne gérait pas les caractères

spéciaux. Le changement de mode d’encodage lors de la lecture ou de l’écriture n’a pas permis de


20

gérer le problème. La création d’un filtrage spécifique à chaque caractère incorrect à donc dû être

mis en place.

3) Description du filtrage

L’état 1 regarde si nous lisons la balise « <div class=g> ». Cette balise symbolise le début du

codage d’un nouveau résultat. Lorsque nous trouvons cette balise nous passons à l’état 2.

L’état 2 regarde si le caractère courant est « " ». Ce caractère symbolise le début de l’url.

Lorsque nous trouvons ce caractère nous passons à l’état 3. Si on trouve le caractère « "w » ou

« " http://news.google » nous passons à l’état 11 car ces résultats ne correspondent pas à ce que

l’on souhaite afficher.

L’état 3 regarde si le caractère courant n’est pas « " ». Ce caractère symbolise la fin de l’URL.

Lorsque nous trouvons ce caractère nous passons à l’état 5. Tant que nous ne trouvons pas ce

caractère nous mettons tous les caractères parcourus dans la variable URL. Durant le remplissage de

la variable URL, nous filtrons les caractères spéciaux.


21

L’état 5 regarde si le caractère courant est « > ». Ce caractère symbolise le début du titre.

Lorsque nous trouvons ce caractère nous passons à l’état 6. Si le caractère courant est « >_ », nous

passons à l’état 11.

L’état 6 regarde si le caractère courant n’est pas « </a> » ou « <br> ». Ces balises symbolisent

la fin du titre. Lorsque nous trouvons ce caractère nous passons à l’état 8. Tant que nous ne trouvons

pas ces caractères nous remplissons la variable titre avec les caractères lus. Durant le remplissage de

la variable titre, les caractères spéciaux sont filtrés.

L’état 8 regarde si le caractère courant est « size=-1> » Lorsqu’est trouvé cette balise nous

passons à l’état 9. Cette balise désigne le début du commentaire. Si est trouvée la balise « size=-

1><sp » nous passons à l’état 10. Cette balise désigne une absence de commentaire.

L’état 9 regarde si la balise « <br> » est présente. Cette balise désigne la fin du commentaire.

Lorsque cette balise est trouvée nous passons à l’état 10. Tant qu’elle n’est pas trouvée, nous

complétons la variable commentaire avec les caractères lus.

L’état 10 est l’état final. Dans cet état toutes les variables précédemment remplie sont

sauvegardées dans le fichier XML. Ensuite nous réinitialisons ces variables à vide. Et pour finir nous

repassons à l’état 1.

L’état 11 est l’état « poubelle ». Les résultats non souhaités sont redirigés, les variables

vidées et on retourne à l’état 1.


22

V. Module « Affichage 3D » :

1) Analyse :

Le module d’affichage dynamique des pages web doit permettre d’afficher plusieurs pages

web en même temps dont une principale ouverte en « pré-consultation ». Elle doit être soit

cliquable directement (accès aux liens de la page) et permettre l’affichage classique de la page, soit

une simple image de la page web et suite à un clique permettre l’affichage classique de celle-ci. Cela

dépendra des capacités techniques du module de rendu de page web.

Le problème se pose lorsque la page est en cours de pré-consultation :

Si le module affiche celle-ci en taille réel, le cadre de la page de pré-consultation sera trop

petit pour une bonne navigation et dans ce cas il sera alors nécessaire d’afficher seulement

une image redimensionnée de la page en cours de pré-consultation.

Si le module est capable d’afficher une page web en taille réduite, mais tout en gardant

cliquable les liens que contient celle-ci (donc pas sous forme d’image), alors on pourra

utiliser ce rendu « réduit » de la page web pour l’affichage de la page en cours de pré-

consultation.

Cela ne pourra être évalué que lors du développement du module.

On limitera le nombre des pages web affichées à 10 maximums en même temps.

Plusieurs affichages peuvent être possibles, reste à définir le plus ergonomique pour la

navigation entre les pages web. Pour le moment une seule présentation sera réalisée :

Une présentation centrale de la page web en cours de pré-consultation et les autres pages en

perspective plus ou moins forte (à définir).

Les pages non pré-consultées sont disposée à droite et les pages déjà pré-consultées à

gauche. On gardera toujours 4 pages maximums à droite et 4 pages maximums à gauches (sauf dans

le cas ou aucune page n’a été pré-consultée pour le moment).

L’utilisateur pourra revenir sur les pages de droite ou de gauche grâce:

à la molette

aux touches directionnelles du clavier

aux boutons placés en dessous des pages

Lors d’une de ces actions, la première page à droite passe au centre et la page centrale passe

en première page à gauche. La dernière page à gauche sort du champ et une autre non pré-consultée

arrive à droite en dernière page, et inversement dans le cas d’un retour vers les premières pages déjà

pré-consultées.


23

2) Développement :

Le WebFlow est une interface utilisateur optimisé pour l’affichage des sites internet, tout

comme le CoverFlow d’Apple l’est pour les pochettes d’albums. Le but de cette présentation

particulière est de pousser au maximum l’ergonomie des recherches sur internet, en l’occurrence sur

Google.

Il était initialement prévu d’utiliser le WebFlow dans 3 cas :

La présentation des résultats d’une recherche Google

La présentation des historiques de navigation

La présentation des favoris

Le WebFlow n’a pas été utilisé pour ces deux derniers points, faute de temps. En effet, il a

été décidé comme primordial d’aboutir à une présentation des résultats en WebFlow performante,

plutôt que de venir au bout des 3 utilisations du WebFlow, et en négliger les performances.

Réalisation du WebFlow :

La réalisation du WebFlow a nécessité beaucoup de temps, tout d’abord à cause de l’aspect

3D de la présentation (connaissance faible en 3D), puis par l’apprentissage du langage et la mise en

place de la solution.


24

Développement du visuel uniquement avec des images :

Tout d’abord, il a fallu développer l’affichage d’images selon le style « Flow », pour cela

plusieurs fonctions et méthodes on été crées :

La fonctions CreateVisual permet de créer un élémet Visual contenant une Image, c’est aussi dans cette fonction que l’on créer l’evennement permettant le clique sur une image pour que celle-çi devienne l’image central.

La fonction CreateGeometry3D permet de créer la géométrie à appliquer à l’image, et donc de définir comment celle-çi doit être affichée.

La fonction CreateEmptyTransform3DGroup permet de définir l’ensemble des vecteurs de transformations qui seront modifiables par la suite pour appliqué des transformations.

La fonction CreateInteractiveVisual3D permet de créer un élément à partir d’une image qui sera affichable sur l’élément parent, ici un élément du type viewport3D. Cette fonction fait appel au 3 précédentes.

La procédure LoadImageToViewport3D permet à partir d’un ensemble d’image (contenu au début dans un dossier spécifique, puis par la suite dans un élément de type Dictionary) de créer chaque image dans le viewport et de les disposés par l’appel de la méthode ReLayoutInteractiveVisual3D.


25

Méthode de disposition des images : La disposition des images nécessite une indexation des images : Chaque image est référencée par un ID, il existe un ID spécial appelé CurrentMidIndex qui prend la valeur de l’id de l’image central. Lorsque l’utilisateur clique sur une image qui n’est pas au centre, CurrentMidIndex prend la valeur de l’ID de l’image cliquée. Un écouteur permettant de déclencher un événement permet de modifier l’aspect visuel général dès que CurrentMidIndex est modifié : la procédure Get ReLayoutInteractiveVisual3D est appelée à chaque changement de CUrrentMidIndex, elle permet de repositionner chaque élément à sa nouvelle position en appelant la méthode GetTransformOfInteractiveVisual3D qui lui indique les différentes positions des éléments en fonctions de leurs Id. Chaque image se positionne par rapport à l’indicateur d’index central CurrentMidIndex. Développement du visuel avec des objets Site_Web :

Après la réalisation d’un simple affichage d’image il a fallu mettre en place

l’affichage pour les résultats, et ce en commençant par créer une structure

Site_Web :

Chaque site web affiché sera donc modéliser sous forme d’une structure

Site_Web contenant une description, un titre, une URL, une ID et une image (view).

Un constructeur permet de créer un objet de type Site_Web.

L’ensemble des sites représentés sont placés dans un Dictionnary (tableau

<clé, valeur>), la clé est l’id du site et la valeur est l’objet Site_Web. Ainsi le

Dictionnary est parcourus pour afficher les éléments.

Dans un premier temps, plusieurs objets Site_Web on été créé pour la phase de test et une

zone d’affichage des informations (titre et description) a été mise en place.


26

Intégration du module « Recherche » :

Le module recherche comprend la gestion du fichier XML et les méthodes d’accès aux

informations des Site_Web résultats d’une recherche.

L’intégration a donc été relativement aisée, puisque il y avait peu de changement à apporté à

l’affichage précédemment développé. Le module recherche ayant une méthode de création du

Dictionnary de Site_Web, celle-ci a été utilisée de la même façon que dans la phase de test

précédent.

Les images des sites sont à la base chargées aves une image par défaut et celles-ci sont mise

à jour au fur et à mesure grâce au module de prévisualisation GenPreview qui permet de charger

deux images en même temps et passer au suivantes automatiquement.

De plus le nombre de résultats visualisable a été limité à 50 car un utilisateur ne va que très

rarement voir jamais consulter les résultats au delà du cinquantième.

Finalement, le module Affichage intégrer avec le module recherche a été développé comme

un contrôle, ce qui a permis une intégration très facile dans l’application globale (une seule ligne de

code suffit).


27

VI. Module « barre de navigation » :

1) Analyse :

Ce module regroupe les options de navigation au sein d’un objet Gecko mais également le

système de navigation au sein de l’application : navigation par onglet.

Nous allons utiliser une barre de navigation avec les options classique tel que :

Retour arrière, avant

Page d’accueil

Raccourcis vers les favoris

Raccourcis vers l’historique

Champ de recherche

URL de la page active

Dans le but d’obtenir un affichage rapide des pages et de gérer la prévisualisation de

plusieurs pages avec un pré-chargement pour la présentation des résultats d’une recherche, il va

falloir mettre en œuvre un buffer de 10 objets Gecko chargés en mémoire.

A chaque objet sera associé les méthodes citées ci-dessus. La méthode de gestion des pages

précédentes et suivantes va imposer la mise en place d’un tableau permettant de sauvegarder les url

visitées par l’utilisateur. Un pointeur devra permettre de positionner l’url en cours de visualisation

par l’utilisateur. Il sera ainsi possible de générer la liste des url pour les méthodes « retour arrière »

et « retour avant ».

Voici un schéma explicatif :

URL POINTEUR

http://www.microsoft.fr

http://www.pinnula.fr

http://www.jean-emile.com

http://www.apple.com *

http://www.mozilla.org

http://search.live.com

http://www.yahoo.fr

http://laposte.net

http://voila.fr

http://mail.live.com

Pour finir, chaque objet Gecko décrit précédemment sera associé à un onglet dans

l’application. Cela permettra une navigation par onglet et donc l’ouverture de plusieurs sites de

manière simultanée dans une seule et même fenêtre.

Pages précédentes

Pages suivantes

Page en cour de prévisualisation

http://www.microsoft.fr/

http://www.pinnula.fr/

http://www.jean-emile.com/

http://www.apple.com/

http://www.mozilla.org/

http://search.live.com/

http://www.yahoo.fr/

http://laposte.net/

http://voila.fr/

http://mail.live.com/


28

Voici une analyse de la relation de la barre de navigation avec le buffer des dix objets Gecko

et un objet Gecko :

1

1

1

1

Barre de navigation

¤ id_obj_buff : integer

Navigate()

Next()

Back()

Home()

Stop()

Go()

Main

BufferGecko

¤ objet1 : gecko

¤ objet2 : gecko

¤ objet3 : gecko

¤ objet4 : gecko

¤ objet5 : gecko

¤ objet6 : gecko

¤ objet7 : gecko

¤ objet8 : gecko

¤ objet9 : gecko

¤ objet10 : gecko

gecko

¤ tab[] : integer,string

Navigate()

Next()

Back()

Home()

Stop()

Go()

1

1..*

*

Onglet

¤ objet : onglet

Close()

1..*


29

Voici une maquette pour l’implémentation de la barre de navigation et des onglets :

2) Développement :

Le développement de cette partie du projet n’a pas posé de problèmes majeurs. Sa

réalisation est restée fidèle au modèle décidé lors de la phase d’analyse.

Voici le résultat de l’implémentation de la barre de navigation et des onglets au sein de Nactus :

La partie barre de navigation a consisté en la réalisation des composants WPF qui la

compose. Un composant « UrlBox » et « SearchBox » ont été réalisés. Le composant « UrlBox »

permet de gérer l’url de la page en cours de visualisation. On peut également lancer le chargement

d’une nouvelle page depuis celle-ci. Enfin, elle permet d’afficher le statut de chargement de cette

dernière par l’intermédiaire d’une flèche verte et d’une croix rouge. La flèche verte montre que l’on

peut démarrer un nouveau chargement. La crois rouge permet d’arrêter le chargement d’une page.

Le composant « SearchBox » permet simplement de lancer une nouvelle recherche en utilisant

l’aperçu des résultats d’une recherche sous forme de webflow.

Nactus

x Site 1 Site 2 Site 3

m

en

u

http://nactus.pinnula.fr


30

Une amélioration possible de cette barre de navigation est l’affichage d’une liste des pages

précédents et suivantes mise en cache afin que l’utilisateur puisse simplement se balader dans

l’historique de navigation de l’onglet ouvert.

Concernant l’implémentation des onglets, les principales difficultés ont résulté dans leurs

positions dans la barre qui les accueille. En effet, la fermeture d’un onglet doit repositionner

l’ensemble des onglets qui le suive ainsi que de changer le focus de l’onglet actuellement ouvert. De

même, les statuts de la page qui prend le focus doivent être « remontés » jusqu’à la barre de

navigation afin que celle-ci reflète les bonne informations.

Les améliorations de cette partie sont nombreuses. Nous pouvons envisager de mettre un

onglet fictif qui permettra d’ouvrir un nouvel onglet. De même, la présence d’une page qui regroupe

l’ensemble des onglets ouverts avec une capture visuelle les représentants permettrait

d’amélioration ergonomie du logiciel.

Les différents composants communiquent via une toile d’évènement qui s’emboitent les un

aux autres pour faire monter et descendre l’ensemble des informations. C’est évènement sont

principalement ceux qui sont présent dans la classe d’implémentation du moteur de rendu (cf.

description de la classe « Gecko »).

Enfin, lorsque nous souhaitons aller sur la page d’accueil, nous faisont appel à un paramètre

stocké dans le répertoire Nactus situé dans le répertoire « Application Data » de la session de

l’utilisateur sur Windows XP et Windows Vista. Ce paramètre est stocké dans un fichier XML.

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<homepage url="http://www.google.fr/" />

</configuration>


31

Celui-ci peut être modifié via des interactions de menu sur les onglets ou via une boîte de

dialogue :


32

VII. Module « favoris » :

1) Analyse :

Le système de favoris sera composé des fonctionnalités classiques suivantes :

Ajout de favoris : Possibilité de créer un dossier et d’insérer le favori là où l’utilisateur le désire.

Rechercher un favori : Permet de retrouver simplement à partir d’un ou plusieurs mots les favoris concernés

Trier par nom : Permet de trier l’ensemble des favoris par leur nom (ordre alphabétique ou inversé)

Nouveau dossier : Permet de créer un nouveau dossier dans l’arborescence des favoris

Ouvrir dans onglets : Permet d’ouvrir un favori dans un nouvel onglet ou une nouvelle fenêtre sans écraser la page en cours de visualisation.

Prévisualisation : Pour aider l’utilisateur à mieux se retrouver dans son panel de favoris, une capture d’écran sera disponible pour avoir un aperçu visuel de ce dernier.

En plus de ces fonctionnalités classiques le module favoris devra vérifier les liens : doublons,

invalides (erreur 404 : page n’existe pas ou plus) et devra indiquer à l’utilisateur les liens invalides ou

en doubles pour qu’il choisisse s’il veut ou non supprimer ces derniers.

Le système devra, dans le cas de doublons, mettre le lien le plus ancien en avant pour aider

l’utilisateur à faire son choix en comparant les dates de dernière modification en priorité sinon la

date de dernière visite et puis si aucune des deux comparaisons n’a de « résultats », il comparera

avec la date d’ajout. Les liens qui ont un différent domaine devront être vérifiés, mais qui arrivent

sur la même page.

Le XML sera utilisé pour stocker les favoris car le XML permet de structurer/stocker

facilement les informations. On peut représenter le schéma XSD correspond aux diverses

informations et la manière dont elles seront stockées. Voici le schéma XSD :



<xs:element name="favoris"/>

<xs:complexType name="folder">

<xs:sequence>

<xs:element name="title" type="xs:string" use="required"/>

<xs:element name="parent" type="xs:positiveInteger"

use="optional"/>

</xs:sequence>

<xs:attribute name="id" type="xs:positiveInteger"

use="required"/>


33

</xs:complexType>

<xs:complexType name="item">

<xs:sequence>



<xs:element name="add" type="xs:date" use="required"/>

<xs:element name="lastvisit" type="xs:date"

use="optional"/>

<xs:element name="lastmodif" type="xs:date"

use="optional"/>

<xs:element name="preview" type="xs:base64Binary"

use="required"/>

</xs:sequence>


use="required"/>

<xs:attribute name="parent" type="xs:positiveInteger"

use="optional"/>

</xs:complexType>

</xs:schema>

Le logiciel lira le fichier XML et l’affichera selon le schéma ci-dessus. Une arborescence est

prise en charge par celui-ci de manière à pouvoir mettre un favoris dans un répertoire qui lui-même

peut être mis dans un autre répertoire. Cela ce schématise comme ceci :

folder

id (1) title (xxx) parent ()

folder

id (2) title (xxx) parent (1)

folder

id (3) title (xxx) parent (2)

item

id (4) … parent ()

item

id (5) … parent (2)

item

id (6) … parent (3)

Racine


34

2) Développement :

Lors de la conception du module favori, certains problèmes se sont posés. Le principal étant

la difficulté d’adaptation à la manipulation et la compréhension du format XML. Ce format est ici utilisé pour le stockage de favoris (titre, url, date d’ajout….).

Ce module contient des fonctions servant a effectuer toutes les opérations classique sur les favoris présent dans les navigateurs classique. Notre module de favoris comporte les fonctionnalités suivantes :

- Ajout/suppression de favoris : Permet de créer un dossier et d’insérer le favori là où l’utilisateur le désire.

- Nouveau dossier /supprimer dossier :

Permet de créer un nouveau dossier dans l’arborescence des favoris

- Lire Permet de représenter le fichier XML sous forme d’arbre, essentiel pour les phases de test

- Create folder

Permet de créer un dossier dans le répertoire application data, où sont stockés les différents fichiers paramètres de notre navigateur.

- Importer

Permet d’importer des favoris à partir d’un fichier HTM ou HTML généré par les navigateurs traditionnel comme IE ou firefox.

- Exporter Permet d’effectuer l’opération inverse d’importer, le navigateur génère un fichier htm où sont stocker les différents favoris de Nactus.

Nous avons aussi eut des difficultés lors du traitement des fonctionnalités importer et exporter,

nous avons du prendre en mains les expressions régulières pour traiter le code HTM. Il y’a eu des problèmes avec la gestion de l’indentation des dossiers, problèmes résolus grâce à un compteur incrémentant et décrémentant le nombre de balise fermante des différentes parti du code HTM.

- Liste dossiers Cette fonction sert dans l’affichage graphique des aperçus, l’utilisateur doit pouvoir visualiser les différents dossiers tout en pouvant visualiser les différents favoris du répertoire courant.

Ce module a posé les bases de notre travail, c’est celui qui nous a pris le plus de temps car

c’est grâce a cette première partie que nous avons pris en main les outils nécessaires aux deux facettes de notre travail.


35

VIII. Module « historique » :

1) Analyse :

Un système d’historique est utilisé avec les fonctionnalités classiques :

Rechercher un lien dans l’historique : Permet de retrouver simplement à partir d’un ou plusieurs mots les sites concernés

Trier par date et site : Permet de trier l’ensemble des historiques par leur nom (ordre alphabétique ou inversé)

Ouvrir dans onglets : Permet d’ouvrir un favori dans un nouvel onglet ou une nouvelle fenêtre sans écraser la page en cours de visualisation

Trier par nom : Permet de trier l’ensemble des favoris par leur nom (ordre alphabétique ou inversé).

Le système devra ajouter les sites visités à l’historique. Si un site est visité plusieurs fois par

jour, un compteur de visites sera incrémenté. L’historique organisera les liens par leur date par

défaut. Les liens qui ont la même date seront dans le même dossier qui aura comme nom la date (ou

aujourd’hui, hier, avant-hier).

Un item de l’historique (un site) pourra avoir plusieurs dates dans le sens ou celui-ci peut être

visité plusieurs jours de suite. Pour ne pas perdre d’informations, chaque jour doit être enregistré.

L’historique utilisera comme les favoris le langage XML pour les mêmes raisons. Le schéma

XSD qu’utilisera l’historique sera le suivant :



<xs:element name="history"/>

<xs:complexType name="item">

<xs:sequence>



<xs:element name="preview" type="xs:base64Binary"

use="required"/>

</xs:sequence>


use="required"/>

</xs:complexType>

<xs:complexType name="visit">

<xs:sequence>

<xs:element name="day" type="xs:date" use="required"/>

<xs:element name="nb" type="xs:positiveInteger"

use="required"/>

</xs:sequence>


36

<xs:attribute name="parent" type="xs:positiveInteger"

use="required"/>

</xs:complexType>

</xs:element>

</xs:schema>

Voici également un schéma expliquant la sauvegarde de plusieurs dates pour un item :

Pour que les données soient cohérentes, il faut vérifier que chaque « item » est composé

d’au moins un « visit ». Dans le cas contraire, cela signifierais qu’un site na jamais été visité.

2) Développement :

Le module historique repose sur les mécanismes utilisé dans le module favoris. Le format de stockage étant le même, il a été possible d’adapter le code pour pouvoir l’utiliser dans un gestionnaire d’historique. Cette seconde partie repose plus sur une phase d’adaptation qu’une phase de création comme celle du module favori.

Les fonctionnalités que nous avons développez pour ce module sont :

- Ajout/suppression d’un lien dans l’historique : Ces deux fonctionnalités dérivent directement du module favori avec des modifications quand aux champs utilisés pour chaque objet complexe du code XML.

- Trois façons de trier les favoris : Nous avons Imaginé trois façon de ranger sont historique afin d’aider l’utilisateur a retrouvé un lien en particulier. Il y’a d’abord le tri classique par date, le tri par domaine et le tri par

item

id (1)

visit

date (12/12/2007) nb (6) parent (1)

visit

date (13/12/2007) nb (2) parent (1)

visit

date (14/12/2007) nb (3) parent (1)


37

fréquence. Ces trois façons de ranger l’historique dérive directement de la fonctionnalité exporté du module favori.

Les difficultés rencontrées dans ce module viennent de la difficulté de lecture des différents tris, en effet la solution retenue fut de créer des fichiers contenant les différents classements de l’historique et de les afficher selon les besoins de l’utilisateur.

Fonctionnement : Le système peut rajouter les sites visités à l’historique. Si un site est visité plusieurs fois par

jour, un compteur de visites sera incrémenté. L’historique organisera les liens par leur date par

défaut. Les liens qui ont la même date seront dans le même dossier qui aura comme nom la date (ou

aujourd’hui, hier, avant-hier).

Un item de l’historique (un site) peut avoir plusieurs dates dans le sens où celui-ci peut être

visité plusieurs jours de suite. Pour ne pas perdre d’informations, chaque jour doit être enregistré.

Durant la réalisation de l’historique nous nous sommes rendu compte que l’attribut

« parent » dans « visit » était inutile donc on obtient le schéma suivant pour l’historique

item

id (1)

visit

date (14/12/2007) nb (3)

visit

date (13/12/2007) nb (2)

visit

date (12/12/2007) nb (6)


38

IX. Conclusion

Après plusieurs mois de travail sur le projet « Nactus », de la phase d’analyse, à la phase de

développement puis des phases de tests et d’intégrations, le navigateur internet est opérationnel.

Grâce à la répartition des tâches, les objectifs principaux ont été réalisés dans les temps.

Le découpage en module a favorisé l’intégration de tout, motivant chacun à l’élaboration de

son module.

La découverte d’un nouveau langage de programmation a été très enrichissante et nous

procure une expérience supplémentaire.

Le projet présent est finalisé et utilisable. Il est disponible sur http://nactus.pinnula.fr via

l’intermédiaire d’un installeur msi. Cependant, son utilisation peut parfois être problématique au

niveau de la ressource mémoire. Cette facette de Nactus peut parfaitement être corrigée en

modifiant certaines classes dont celle qui génère dynamiquement le webflow.

Nactus est également évolutif du fait du nombre important de tâches optionnelles énoncées

lors de l’analyse, et qui pourront faire l’objet d’une nouvelle étude.

http://nactus.pinnula.fr/


39

X. Annexe

1) Exemple complet :

On désire dans cet exemple montrer le déroulement d’une recherche du début à la fin.

Chaque étape sera accompagnée d’un morceau du code et d’image afin de montrer le déroulement.

Une recherche commence par la récupération du code source de Google et de son écriture

dans un fichier texte.

// On crée la requette en direction de google

HttpWebRequest request =

(HttpWebRequest)WebRequest.Create("http://www.google.fr/search?hl=fr&q=" + mot_clé + "&start="

+ num_debut + "&num=" + intervalle);

// On obtient la réponse

HttpWebResponse response = (HttpWebResponse)request.GetResponse();

// On récupère les données du serveur

Stream dataStream = response.GetResponseStream();

// On ouvre le résultat dans un fichier de lecture

StreamReader reader = new StreamReader(dataStream, Encoding.Default);

// On lit le fichier jusqu'a la fin

string responseFromServer = reader.ReadToEnd();

// On écrit dans le fichier

StreamWriter sw = new StreamWriter(fichier, false, Encoding.UTF8);

sw.Write(responseFromServer);

Une fois le code

source récupéré, il

s’agit maintenant de le

filtrer afin

d’enregistrer dans le

fichier XML juste les

sites web.


40

La création du fichier XML s’effectue par la méthode CreationXml(string fichier_source).Il est

créé dans le dossier temporaire de la session en cours.

//Création du fichier temporaire dans lequel est écrit les résultats sous forme XML

XmlTextWriter docxml = new XmlTextWriter(this.path + "\\recherche.xml", Encoding.UTF8);

switch (etat){

……… //Filtrage du code source

}

//Ecriture dans le fichier XML

docxml.WriteStartElement("ResultSearch");

docxml.WriteAttributeString("id", num_recherche.ToString());

docxml.WriteStartElement("url");

docxml.WriteString(url);

docxml.WriteEndElement();

docxml.WriteStartElement("titre");

docxml.WriteString(titre);


docxml.WriteStartElement("description");

docxml.WriteString(description);



//Passage au Site suivant et initialisation des variables

num_recherche++;

etat = 1; url = "";

description = "";

titre = "";


41

Ensuite grâce à la structure qui retourne des « Site web », le module Affichage 3D génère les

aperçus.

Méthodes de calcul de la disposition d’une image en fonction de son ID par rapport au

CurrentMidIndex :

private void GetTransformOfInteractiveVisual3D(int positiondsindex, double milieuIndex, out

double angle, out double offsetX, out double offsetZ, out double offsetY)

{

double positionprcentre = positiondsindex - milieuIndex;

//calcul de la position de l'image en cours par rapport à l'image centrale

offsetY = 0;

angle = 0; //initialisation de l'angle à 0

if (positionprcentre < 0)

{

angle = 55;//Si l'image est à gauche alors l'angle vaut 55

}

else if (positionprcentre > 0)

{

angle = (-55);//si l'image est à droite il vaut -55

}

offsetX = 0; // initialitsation

if (Math.Abs(positionprcentre) <= 1)

//positionnement des deux images proches de la centrale

{

offsetX = positionprcentre * 2;

}

else if (positionprcentre != 0) //positionnement des autres images

{

offsetX = positionprcentre * 1 + (positionprcentre > 0 ? 1 : -1);

}

offsetZ = Math.Abs(positionprcentre) * -1; // -1 = profondeur des images de côtés

if (positionprcentre == 0)//postionnement spécial de l'image centrale

{

offsetY = -0.3;

offsetZ = 4.5;

}

}


42

Pour finir le nouveau Web Flow est intégré dans le navigateur. Le worflow étant développé sous

forme de composant, il suffit de l’inclure à l’endroit voulu en l’nitialisant.


43

2) Description des classes :

a. Module « Gecko » :

Cette classe permet d’implémenter l’objet COM Gecko au sein de l’application. Les fonctions

de base du navigateur sont également mappées.

Méthodes

public Gecko(NavigateTab sender, int id)

Initialise la classe avec les paramètres par défaut. L’objet « barre de navigation » implémenté au sein de l’application ainsi que l’id de la page concernée par l’objet Gecko sont passé en paramètre.

private void axGecko_OnQuit(object sender, EventArgs e)

Evènement appelé lorsque le moteur de rendu décide de se fermer.

private void axGecko_LocationChanged(object sender, EventArgs e)

Evènement appelé lorsque l’url change.

private void axGecko_BeforeNavigate2(object sender,

AxMOZILLACONTROLLib.DWebBrowserEvents2_BeforeNavigate2Event e)

Evènement appelé avant que le moteur de rendu ne commence à charger une page.

private void axGecko_NavigateComplete2(object sender,

AxMOZILLACONTROLLib.DWebBrowserEvents2_NavigateComplete2Event e)

Evènement appelé lorsque la page a terminé de se charger.

private void axGecko_NewWindow2(object sender,

AxMOZILLACONTROLLib.DWebBrowserEvents2_NewWindow2Event e)

Evènement appelé le moteur de rendu demande l’ouverture d’une nouvelle page.

public void Navigate(string url)

Méthode qui permet de lancer le chargement d’une page.

public void GoBack()

Méthode qui permet de faire un retour en arrière.

public void GoHome()

Méthode qui permet de démarrer le chargement de la page d’accueil enregistrée dans les paramètres de Nactus. Cette méthode appel une autre méthode abstraite qui permet de lire la donnée enregistrée dans un fichier XML dans les dossiers de configuration de l’application Nactus de la session Windows sur laquelle il s’exécute.

public void Stop()


44

Méthode qui permet d’arrêter le chargement de la page.

public void GoForward()

Méthode qui permet de faire un retour en avant dans la navigation.

public void RefreshG()

Méthode qui permet de rafraichir une page.

public void DisposeG()

Méthode qui permet de détruire l’objet Gecko et de libérer la mémoire qui lui est associé.

private void axGecko_TitleChange(object sender,

AxMOZILLACONTROLLib.DWebBrowserEvents2_TitleChangeEvent e)

Evènement qui déclenché lorsque le titre de la page change.

public String getTitle()

Méthode qui permet d’obtenir le titre de la page.

public String getUrl()

Méthode qui permet d’obtenir l’url de la page.

public object getApplication()

Méthode qui permet d’obtenir la propriété « Application » dans le cadre de l’ouverture d’un popup lors du clic sur un lien dans une page web.


45

b. Module « Génération des aperçus » :

Cette classe permet de générer une image au format 800x600 représentant un site web.

Cette taille peut être modifiée via deux variables dans le constructeur de cette classe.

Méthodes

public GenPreview()

Initialise la classe avec les paramètres par défaut. La taille de l’image en sortie peut-être changée dans le constructeur de cette classe.

public void ObtainPreview(String url, int id)

Demande la création d’un aperçu de la page dont l’url est passée en paramètre.

private void _gecko_DocumentComplete(object sender,

AxMOZILLACONTROLLib.DWebBrowserEvents2_DocumentCompleteEvent e)

Génère l’évènement qui transmet l’aperçu une fois que celle-ci est créée.

private static BitmapSource loadBitmap(System.Drawing.Bitmap source)

Transforme un objet de type Bitmap en BitmapSource.

public event ImageGeneratedEventHandler OnImageComplete;

avec

public delegate void ImageGeneratedEventHandler(GenPreview Gen,

System.Windows.Controls.Image img, int id);

Evènement qui renvoi un objet de Type Image (WPF), l’id de la page générée (position au sein de la recherche) ainsi

que l’objet de Type GenPreview qui vient de générer cet aperçu.

Conseils :

Un aperçu est égal à la création d’un objet de type GenPreview. Si on veut trois aperçu de

trois site différent, on créé trois objets de type « GenPreview » et on demande les aperçu. Il doit

y avoir trois évènements de prévu.

Pour générer trois aperçus avec un seul composant, il suffit de demander la génération d’une

autre url lors de l’évènement qui est déclenché une fois qu’un aperçu est créé. L’objet est passé en

paramètre. Il suffit de rappeler la méthode ObtainPreview().


46

c. Module « Recherche » :

Classe Recherche :

Classe principale du module, elle récupère le code source, le filtre et crée le fichier XML.

public Recherche(String mot_clé, int num_debut, int intervalle, string fichier)

Le constructeur de la classe Recherche, il permet de récupérer le code source de google et de générer un fichier texte possédant celui-ci.

- « mot_clé » : le mot ou la phrase de la recherche. - « num_début » : par défaut à 0, ensuite il permet de choisir la recherche de départ - « intervalle » : par défaut à 10, sinon définie le nombre de résultat voulu (maximum 15 dû à la taille

maximal du fichier texte). - « fichier » : le fichier de sortie possédant le source

public void nombre_resultats(string fichier_source)

Méthode qui permet de récupérer le nombre de résultat de la recherche. Deux conditions sont retournées, soit la recherche à donner un ou plusieurs résultats, soit aucun résultat n’a été trouvé. Elle prend en paramètre le fichier contenant le code source.

public void CreationXml(string fichier_source)

Cette méthode crée le fichier xml. Elle fait appelle à la méthode nombre_resultats(). Si il n’y a pas de résultat alors on crée un fichier XML vide. Si il existe des résultats, on parcours le fichier source caractère par caractère. On filtre ces caractères pour obtenir l’url, le titre et la description de chaque résultat de recherche. La première ligne du fichier XML est la déclaration du type de fichier. Ensuite on met une balise « englobante » qui prendra tous les résultats. Ensuite on a une nouvelle balise avec un identifiant (le numéro du résultat de la recherche). Dans cette balise se trouve les balises d’url, de titre et de description.

Classe Parse_Recherche :

Classe qui fait suite à une recherche, elle permet de créer un objet « Site Web » en allant

chercher les informations dans le fichier XML précédemment créé.

public struct Site_web

Création d’une structure permettant la création d’un « Site ». Elle contient un numéro id du site, l’URL, le titre, la description et l’mage par défaut lors de l’attente de l’apperçu des preview. Elle est construit grâce à son constructeur : public Site_web(int id, String Url , String Titre, String Windows. Image view).

public System.Windows.Controls.Image creimg(int idRecherche, XmlDocument docXml)

Cette méthode crée l’image d’attente au format .bmp.

public string getURL(int idRecherche,XmlDocument docXml)


47

public string getTitre(int idRecherche, XmlDocument docXml)

public string getDescription(int idRecherche, XmlDocument docXml)

Ces trois méthodes permettent de remplire la structure créant un « Site ». Elles se chargent de récupérer dans le fichier XML précédamment créé, en fonction du numéro de recherche voulue, l’URL ou le titre ou la description grâce au élément du document XML. Ex : GetElementsByTagName("url"), lorsque dans le document XML on trouve cet élément on récupère l’URL correspondant.


48

d. Module « Affichage 3D » :

private Visual CreateVisual(Image imageFile, int index)

La fonctions CreateVisual permet de créer un élémet Visual contenant une Image, c’est aussi dans cette fonction que l’on créer l’evennement permettant le clique sur une image pour que celle-çi devienne l’image central.

private Geometry3D CreateGeometry3D()

La fonction CreateGeometry3D permet de créer la géométrie à appliquer à l’image, et donc de définir comment celle-çi doit être affichée.

private Transform3DGroup CreateEmptyTransform3DGroup()

La fonction CreateEmptyTransform3DGroup permet de définir l’ensemble des vecteurs de transformations qui seront modifiables par la suite pour appliqué des transformations.

private InteractiveVisual3D CreateInteractiveVisual3D(Image imageFile, int index)

La fonction CreateInteractiveVisual3D permet de créer un élément à partir d’une image qui sera affichable sur l’élément parent, ici un élément du type viewport3D. Cette fonction fait appel au 3 précédentes.

private void LoadImageToViewport3D(Dictionary<int, Site_web> res)

La procédure LoadImageToViewport3D permet à partir d’un ensemble d’image (contenu au début dans un dossier spécifique, puis par la suite dans un élément de type Dictionary) de créer chaque image dans le viewport et de les disposés par l’appel de la méthode ReLayoutInteractiveVisual3D.

public static readonly DependencyProperty CurrentMidIndexProperty =

DependencyProperty.Register(

"CurrentMidIndex",typeof(double),typeof(Window1),

New FrameworkPropertyMetadata(new PropertyChangedCallback

(CurrentMidIndexPropertyChangedCallback)));

Définition de l’évennement déclenché lors du changement de CurrentMidIndex.

private static void CurrentMidIndexPropertyChangedCallback(DependencyObject

sender, DependencyPropertyChangedEventArgs arg)

Cette méthode définie les choses à faire lors du changement de CurrentMidIndex.

private void button1_Click(object sender, RoutedEventArgs e)

Définition de l’écouteur déclenchant le lancement d’une recherche.

private void newrech()

Méthode appelée suite à l’évennement déclencer par l’écouteur button1_Click.

private void tarea_TextChanged(object sender, TextChangedEventArgs e)

Méthode permettant de récupérer les mots clé de recherche.

private void getInfos(Dictionary<int, Site_web> tab_gen)

Méthode permettant de récupérer les infos des différents Site_Web résultats de la recherche effectué, elle utilise les


49

méthodes d’accès aux informations. Finalement elle met tous les Site_Web récupérés dans un Dictionnary.

private void getResu(String mot_cle)

Méthode principale appelant les autres méthodes pour créer le WebFlow dans sa globalité, afficher les informations sur les sites et lancer le chargement des aperçus.

private void changeImageInteractiveVisual3D(GenPreview gen, Image imageFile, int

id)

Méthode permettant de mettre à jour l’image d’un Site_Web déjà afficher dans le WebFlow.

public void Inicomponent()

Méthode d’initialisation des événements.

private void Window1_Wheel(object sender, MouseWheelEventArgs e)

Méthode définissant les actions à faire lorsque l’evennement de la roulette souris est déclencher.

public void Window1_KeyDown(object sender, KeyEventArgs e)

Méthode définissant les actions à faire lorsque l’évennement des touches clavier est déclenché.


50

e. Module « barre de navigation » :

La barre de navigation est composée d’un certains nombre de composants superposés. Ces

composants communiquent entre eux en tissant une toile d’araignée avec des évènements

enchevêtrés.

Les classes des composants sont :

BtnsNavig

NavigateBar

NavigateTab

NavigNavig

OneTab

Page

SearchTextBox

UrlBox

Les évènements déclenchés par la classe Gecko sont repris par l’ensemble des composants

(cf. classe Gecko).


51

f. Module « favoris » :

Classe Favoris :

Descriptif :

Cette classe permet la gestion de favoris. Les opérations élémentaires (ajouter/supprimer des favoris

et des dossiers de favoris, importer, exporter) sont effectuer a travers des méthodes public.

Variables

Path : endroit sur le disque ou serons stocker les fichiers de notre navigateur. numFav : variable contenant le nombre de favoris actuel numFol : variable contenant le nombre de favoris actuel

Méthodes

public Favoris()

Initialise un fichier XML avec comme unique lien Nactus dans l’unqiue répertoire projet.

public String returnPath()

Méthode servant a récupérerl e chemin dans lequel se trouve les favoris du navigateur, elle pourra également être utilisé pour l’historique.

public TreeNode lire(XmlNode xmlNode)

Fonction servant a afficher le contenu d’un fichier XML, le paramétre d’entrée est un fichier XML. Le résultat est un TreeNode.

public void ajoutFavoris(String titre, String url, String idDossier)

Procédure permettant d’ajouter un favoris en prenant comme paramètre le titre d’un site, son adresse, la date ou ce dernier est ajouté et l’id du dossier ou il se trouvera.

public void ajoutDossier(String titre, String idDossier)

Cette procédure semblable a la précédente permet d’ajouter un dossier. Les deux paramètres sont le titre et l’identifiant du dossier dans lequel nous devons insérer le nouveau dossier.

public void supprimerFavoris(String idFav)

Cette fonction supprime le favoris en prenant une identifiant de la structure XML son id.

public void supprimerDossier(String idDos)

Cette fonction est analoghue a la précédente mais s’applique au dossier.

private void createFolder()

Cette procédure créer le dossier Nactus dans le chemin path s’il nexiste pas.


52

public void importerFav(string fichier_entree)

Importe des favoris a partir d’un fichier htm.

public TreeNode ListeDossier(XmlNode xmlNode)

Fourni la liste des dossier sous formes de TreeNode. En plus de cette liste apparaît l’emplacement de base(balise favoris). Cette fonction servira a affiché les favoris d’un dossier, ou de la racine.

public void exporterFav(string fichier)

Procédure généran tun fichier HTM contenant toutes les informations sur les favoris actuel du navigateur.

Exemple :

Favoris fav = new Favoris();

fav.ajoutDossier("Dossier dans dossier", "1");

fav.ajoutFavoris("google", "www.google.fr", "9");

fav.importerFav(@"c:\\bookmark.htm");

fav.exporterFav(@"c:\\BookNactus2.htm");

Classe parse_favoris

Descriptif :

Classe qui fournit une structure site_web, contenant les informations d’un favori.

Variables

public struct site_web : Structure qui permet d’avoir les informations d’un

favori

Path : endroit sur le disque où sont stockés les fichiers de notre navigateur.

Méthodes

public string getURL(int idFold, int numFav, XmlDocument xmlDoc)

Récupère l’url du favoris contenu dans un dossier.

public string getTitre(int idFold, int numFav, XmlDocument xmlDoc)

Récupère le titre du favoris contenu dans un dossier.

public string getAddDate(int idFold, int numFav, XmlDocument xmlDoc)

Récupère la date d’ajout du favoris contenu dans un dossier.

public string getLastVisit(int idFold, int numFav, XmlDocument xmlDoc)

Récupère la date de dernière visite du favoris contenu dans un dossier.


53

public string getLastModif(int idFold, int numFav, XmlDocument xmlDoc)

Récupère la date de dernière modification du favoris contenu dans un dossier.

public System.Windows.Controls.Image creimg(int idDos, int numFav, XmlDocument

docXml)

Crée une image à partir du favoris.


54

g. Module « historique » :

public void ajoutHisto(String titre, String url)

Permet d’ajouter l’url d’un site visité dans l’historique. Pour cela on doit fournir le titre et l’url du site en paramêtre. - Si le lien n’existe pas dans l’historique il est rajouté à la fin du fichier xml. - Si le lien existe déjà et qu’il a déjà été visité à la date du jour alors on incrémentera le nombre de visites du site à

la date. - Si le lien existe et qu’il n’a pas été visité à la date du jour alors juste la date est rajouté à l’item correspondant à

l’url.

public String supprimerLien(String idHist, string date)

Permet de supprimer un lien dans l’historique en indiquant la date à laquelle on veut supprimer le lien. Pour réalisé la suppression nous parcourons le fichier xml en regardant quel item a pour id : « idHist » et ensuite on entre dans l’item et on regarde la date de la visite que l’on veut supprimer et s’il n’y a plus de date de visite l’item est supprimé.

public void triParFrequence(TreeView tv1)

Permet de trier les sites dans l’historique par fréquence de visites, du site le plus visité au moins visité.

public void triParDate(TreeView tv1)

Permet de trier l’historique par date du plus récent au plus ancien.

public void triParDomaine(TreeView tv1)

Permet de trier l’historique ar nom de domaine.

La recherche internet repensée… - univ-rennes1.fr · Enfin, le choix de la technologie WPF pou p...

Documents

Transcript of La recherche internet repensée… - univ-rennes1.fr · Enfin, le choix de la technologie WPF pou p...