Test d'ajout de TOUT mes fichiers (moins ceux mis en git reset HEAD à cause de l'histoire des trailings machins choses)
Cf: http://www.agavemountain.com/2008/01/git-tralining-whitespace-error-during.html
This commit is contained in:
parent
dcd8bcb303
commit
48ff5f7c7a
28
A61/séance4
Normal file
28
A61/séance4
Normal file
@ -0,0 +1,28 @@
|
||||
IDL => Description ! Pas définition !
|
||||
|
||||
Corba n'est pas comme Java, corba est une norme, pas un langage !
|
||||
|
||||
Cette norme n'impose aucun outil. Tout est libre de choix, simplement il faut suivre la norme.
|
||||
|
||||
Ce qui est normé, c'est pas totalement l'appel des méthodes, c'est plutôt ce que font les méthodes quand elles contactent un objet. Elles doivent toujours procéder de la même manière.
|
||||
|
||||
idlj est une commande, donnée par Sun dans un package spécifique.
|
||||
|
||||
ior = identifiant object request
|
||||
|
||||
Une ior commence toujours par la chaîne "ior:", puis 128 caractères (dans les 128 caractères, on a un codage pour gagner de la place, et tout normer / compacter => nom machine, port, date création, et certains droits).
|
||||
|
||||
ior_dump est une commande possible (à chercher), qui permet de décoder les IOR.
|
||||
|
||||
Une ior est valable que la durée d'existance de l'objet. Si on éteind le serveur qu'on le rallume et que nous utilisons les mêmes objets, chacun des objets aura un ior différent de celui qu'il possédait avant. Ceci du fait de la "date de création" !
|
||||
|
||||
|
||||
Pour chaque objet on peut créer des "servant" (genre de valets). Pour chaque objet on définit les servants, pour chacun d'eux on a un IOR différent. Du coup les clients pourront se connecter à un servant spécifique.
|
||||
|
||||
POA = Portable Object Adaptator (le prof croît)
|
||||
|
||||
Corba procède toujours ainsi : Je crée un objet de connexion et je fais un ".narrow"
|
||||
|
||||
De nos jours il faut obligatoirement passer par le POA, l'ancienne technique est dite obsolète.
|
||||
|
||||
|
26
A61/séance4~
Normal file
26
A61/séance4~
Normal file
@ -0,0 +1,26 @@
|
||||
IDL => Description ! Pas définition !
|
||||
|
||||
Corba n'est pas comme Java, corba est une norme, pas un langage !
|
||||
|
||||
Cette norme n'impose aucun outil. Tout est libre de choix, simplement il faut suivre la norme.
|
||||
|
||||
Ce qui est normé, c'est pas totalement l'appel des méthodes, c'est plutôt ce que font les méthodes quand elles contactent un objet. Elles doivent toujours procéder de la même manière.
|
||||
|
||||
idlj est une commande, donnée par Sun dans un package spécifique.
|
||||
|
||||
ior = identifiant object request
|
||||
|
||||
Une ior commence toujours par la chaîne "ior:", puis 128 caractères (dans les 128 caractères, on a un codage pour gagner de la place, et tout normer / compacter => nom machine, port, date création, et certains droits).
|
||||
|
||||
ior_dump est une commande possible (à chercher), qui permet de décoder les IOR.
|
||||
|
||||
Une ior est valable que la durée d'existance de l'objet. Si on éteind le serveur qu'on le rallume et que nous utilisons les mêmes objets, chacun des objets aura un ior différent de celui qu'il possédait avant. Ceci du fait de la "date de création" !
|
||||
|
||||
|
||||
Pour chaque objet on peut créer des "servant" (genre de valets). Pour chaque objet on définit les servants, pour chacun d'eux on a un IOR différent. Du coup les clients pourront se connecter à un servant spécifique.
|
||||
|
||||
POA = Portable Object Adaptator (le prof croît)
|
||||
|
||||
Corba procède toujours ainsi : Je crée un objet de connexion et je fais un ".narrow"
|
||||
|
||||
|
30
A61/séance5
Normal file
30
A61/séance5
Normal file
@ -0,0 +1,30 @@
|
||||
Jeudi 24/04/2008
|
||||
|
||||
5.2 Nommage
|
||||
|
||||
Le service de nommage n'est rien d'autre qu'une application CORBA qui encapsulera un objet en particulier.
|
||||
|
||||
Quand on fait une application :
|
||||
|
||||
* On crée l'ORB
|
||||
* On met en place le service :
|
||||
* Création de l'objet
|
||||
* On doit le connecter sur l'ORB (enficher sur l'ORB)
|
||||
* Ceci permet de créer l'IOR (de 256 caractères) qui permet d'accéder depuis n'importe où dans le monde à votre objet
|
||||
|
||||
On dispose alors d'un serveur CORBA.
|
||||
|
||||
Ensuite, de l'autre côté on fait :
|
||||
|
||||
* Création d'un ORB
|
||||
* Récupération de l'IOR
|
||||
* On crée un objet de connexion à partir de cet IOR
|
||||
* On se connecte
|
||||
* On colle l'interface : faire un NARROW
|
||||
|
||||
Comme on ne connait pas le serveur de départ posséder l'ior, alors on a décidé de demander directement à l'ORB ! Donc on descend d'un niveau pour demander à l'ORB l'ensemble des IOR qu'il possède.
|
||||
|
||||
ORB ne sait résoudre que le problème du nom serveur de noms (objet notoire), qui n'est autre que **NameService**.
|
||||
|
||||
La demande renvoie vers un ORB va permettre de récupérer l'IOR, puis de se connecter à l'objet, et fincalement de se connecter à l'objet.
|
||||
|
123
A62/Cours1
Normal file
123
A62/Cours1
Normal file
@ -0,0 +1,123 @@
|
||||
A62, Jeudi 13 mars 2007
|
||||
|
||||
pulvermuller@dept-info.u-strasbg.fr\\
|
||||
2 cours\\
|
||||
ULP et Caisse d'épargne\\
|
||||
|
||||
====== L'ergonomie et I.C.H.M ======
|
||||
|
||||
Plutôt méthodologique que applicatif
|
||||
|
||||
ICHM = Interface de Communication entre l'Homme et la Machine
|
||||
|
||||
On l'étudie pour éviter de générer des erreurs => Charte d'ergonomie
|
||||
|
||||
But : Capter l'intérêt des utilisateurs et rendre efficace
|
||||
|
||||
Lors de la conception on ne peut ps penser à tout : il faut tester.
|
||||
|
||||
Feedback utilisateur : progression de la tâche
|
||||
|
||||
Adopter les logiciels à l'utilisateur maître
|
||||
|
||||
Principe essentiel : le guidage de l'utilisateur. Ex : campagne d'annonces Google
|
||||
|
||||
Penser aux exemples ou aux aides contextuelles.
|
||||
|
||||
Exemple :
|
||||
* Trame avec visibilité sur le panneau d'affichage
|
||||
* Compte d'étudiant avec plusieurs numéros
|
||||
|
||||
Caisse d'épargne : poste de travail avec 250 applications
|
||||
|
||||
Style ou bouton défini : utiliser toujours le même => lecture iconographique
|
||||
|
||||
Architecture d'imformation : on les découpe en petits morceaux pour les rendre assez compréhensibles et ordonnés
|
||||
|
||||
Pertinence de l'information. Ex : Carte d'accès au site.
|
||||
|
||||
Actions irréversibles => prévoir un message de confirmation qui sert à quelque chose !
|
||||
|
||||
===== Définition =====
|
||||
|
||||
L'ergonomie (ou l'étude des facteurs humains) est la discipline scientifique qui vise à la compréhension fondamentale des interactions entres les êtres humains et les autres composants d'un système.
|
||||
|
||||
Spectre de l'oeil humain . 555 : entre vert et jaune (le plus visible possible)
|
||||
|
||||
3 paramètres :
|
||||
* Teinte
|
||||
* Saturation (vers - gris)
|
||||
* Luminosité
|
||||
|
||||
Utiliser un maximum de 5 couleurs (+/- 2)
|
||||
* rouge (orange et jaune)
|
||||
* vert
|
||||
* bleu (violet)
|
||||
|
||||
Ne pas brouiller la lecture
|
||||
|
||||
Couleurs complémentaires :
|
||||
* Rouge - vert
|
||||
* Bleu - orange
|
||||
* Jaune - violet
|
||||
|
||||
Couleurs différentes selon les messages.
|
||||
|
||||
Les couleurs ont une signification différente selon le pays.
|
||||
|
||||
Distances perçues. Plan des couleurs différent. Dans un texte prendre des couleurs proches.
|
||||
|
||||
9% hommes daltoniens à un degré plus ou moins important.\\
|
||||
0,6% des femmes
|
||||
|
||||
Outils pour voir comme des daltoniens
|
||||
|
||||
Ne pas juxtaposer le rouge et le vert
|
||||
|
||||
Le jaune et le bleau sont bien reconnus. Une forte luminosité et saturation va limiter le problème.
|
||||
|
||||
FAIRE IMAGE ICI
|
||||
|
||||
Processus métier : l'utilisation ne doit pas retenir toutes les informations
|
||||
|
||||
Mnème = quantité d'information connue, familière, traitée par la mémoire à court terme et à caractère d'unité
|
||||
|
||||
Expérience de Conrad :
|
||||
* 8 chiffres => 72,6%
|
||||
* précédé de 0 => 37,5 % réussissent
|
||||
|
||||
Dépassement de capacité = on perd tout
|
||||
|
||||
====== Les critères de BASTIEN (1993) ======
|
||||
|
||||
===== Compatibilité =====
|
||||
|
||||
Adéquation du logiciel vis - à - vis de l'utilisation et de sa classe métier :
|
||||
* ses habitudes
|
||||
* son contexte de travail
|
||||
|
||||
La logique d'utilisation du système doit correspondre à la logique de l'utilisateur.
|
||||
|
||||
===== Le guidage =====
|
||||
|
||||
Tout les moyens mis en oeuvre pour lui permettre de s'orienter :
|
||||
* Faire connaître l'état du système
|
||||
* Liens de causalité entre ses actions et l'état du système
|
||||
|
||||
Faciliter l'apprentissage de l'utilisation
|
||||
|
||||
2 niveaux :
|
||||
* Guidage explicite (évènements et aide)
|
||||
* Guidage implicite (présentation et organisation)
|
||||
|
||||
Incitation :
|
||||
* griser les commandes non disponibles
|
||||
* donner le format de saisie des données
|
||||
|
||||
Lisibilité : les minuscules sont plus faciles à lire, -20% de temps. Éviter l'italique (astigmates)
|
||||
|
||||
===== Homogénéité =====
|
||||
|
||||
Zoning des pages (descendre, monter pour chercher l'information)
|
||||
|
||||
Syntaxe des items de menus (faire courts).
|
123
A62/Cours1~
Normal file
123
A62/Cours1~
Normal file
@ -0,0 +1,123 @@
|
||||
A62, Jeudi 13 mars 2007
|
||||
|
||||
pulvermuller@dept-info.u-strasbg.fr
|
||||
2 cours
|
||||
ULP et Caisse d'épargne
|
||||
|
||||
== L'ergonomie et I.C.H.M
|
||||
|
||||
Plutôt méthodologique que applicatif
|
||||
|
||||
ICHM = Interface de Communication entre l'Homme et la Machine
|
||||
|
||||
On l'étudie pour éviter de générer des erreurs => Charte d'ergonomie
|
||||
|
||||
But : Capter l'intérêt des utilisateurs et rendre efficace
|
||||
|
||||
Lors de la conception on ne peut ps penser à tout : il faut tester.
|
||||
|
||||
Feedback utilisateur : progression de la tâche
|
||||
|
||||
Adopter les logiciels à l'utilisateur maître
|
||||
|
||||
Principe essentiel : le guidage de l'utilisateur. Ex : campagne d'annonces Google
|
||||
|
||||
Penser aux exemples ou aux aides contextuelles.
|
||||
|
||||
Exemple :
|
||||
* Trame avec visibilité sur le panneau d'affichage
|
||||
* Compte d'étudiant avec plusieurs numéros
|
||||
|
||||
Caisse d'épargne : poste de travail avec 250 applications
|
||||
|
||||
Style ou bouton défini : utiliser toujours le même => lecture iconographique
|
||||
|
||||
Architecture d'imformation : on les découpe en petits morceaux pour les rendre assez compréhensibles et ordonnés
|
||||
|
||||
Pertinence de l'information. Ex : Carte d'accès au site.
|
||||
|
||||
Actions irréversibles => prévoir un message de confirmation qui sert à quelque chose !
|
||||
|
||||
=== Définition ===
|
||||
|
||||
L'ergonomie (ou l'étude des facteurs humains) est la discipline scientifique qui vise à la compréhension fondamentale des interactions entres les êtres humains et les autres composants d'un système.
|
||||
|
||||
Spectre de l'oeil humain . 555 : entre vert et jaune (le plus visible possible)
|
||||
|
||||
3 paramètres :
|
||||
* Teinte
|
||||
* Saturation (vers - gris)
|
||||
* Luminosité
|
||||
|
||||
Utiliser un maximum de 5 couleurs (+/- 2)
|
||||
* rouge (orange et jaune)
|
||||
* vert
|
||||
* bleu (violet)
|
||||
|
||||
Ne pas brouiller la lecture
|
||||
|
||||
Couleurs complémentaires :
|
||||
* Rouge - vert
|
||||
* Bleu - orange
|
||||
* Jaune - violet
|
||||
|
||||
Couleurs différentes selon les messages.
|
||||
|
||||
Les couleurs ont une signification différente selon le pays.
|
||||
|
||||
Distances perçues. Plan des couleurs différent. Dans un texte prendre des couleurs proches.
|
||||
|
||||
9% hommes daltoniens à un degré plus ou moins important.\\
|
||||
0,6% des femmes
|
||||
|
||||
Outils pour voir comme des daltoniens
|
||||
|
||||
Ne pas juxtaposer le rouge et le vert
|
||||
|
||||
Le jaune et le bleau sont bien reconnus. Une forte luminosité et saturation va limiter le problème.
|
||||
|
||||
FAIRE IMAGE ICI
|
||||
|
||||
Processus métier : l'utilisation ne doit pas retenir toutes les informations
|
||||
|
||||
Mnème = quantité d'information connue, familière, traitée par la mémoire à court terme et à caractère d'unité
|
||||
|
||||
Expérience de Conrad :
|
||||
* 8 chiffres => 72,6%
|
||||
* précédé de 0 => 37,5 % réussissent
|
||||
|
||||
Dépassement de capacité = on perd tout
|
||||
|
||||
== Les critères de BASTIEN (1993) ==
|
||||
|
||||
=== Compatibilité ===
|
||||
|
||||
Adéquation du logiciel vis - à - vis de l'utilisation et de sa classe métier :
|
||||
* ses habitudes
|
||||
* son contexte de travail
|
||||
|
||||
La logique d'utilisation du système doit correspondre à la logique de l'utilisateur.
|
||||
|
||||
=== Le guidage ===
|
||||
|
||||
Tout les moyens mis en oeuvre pour lui permettre de s'orienter :
|
||||
* Faire connaître l'état du système
|
||||
* Liens de causalité entre ses actions et l'état du système
|
||||
|
||||
Faciliter l'apprentissage de l'utilisation
|
||||
|
||||
2 niveaux :
|
||||
* Guidage explicite (évènements et aide)
|
||||
* Guidage implicite (présentation et organisation)
|
||||
|
||||
Incitation :
|
||||
* griser les commandes non disponibles
|
||||
* donner le format de saisie des données
|
||||
|
||||
Lisibilité : les minuscules sont plus faciles à lire, -20% de temps. Éviter l'italique (astigmates)
|
||||
|
||||
=== Homogénéité ===
|
||||
|
||||
Zoning des pages (descendre, monter pour chercher l'information)
|
||||
|
||||
Syntaxe des items de menus (faire courts).
|
255
A62/Cours2
Normal file
255
A62/Cours2
Normal file
@ -0,0 +1,255 @@
|
||||
A62, 27 mars 2008
|
||||
|
||||
Pour le 9 mai 2008 :
|
||||
* Charte graphique (PDF) => pas de PDF de plus de 10Mo !
|
||||
* Charte ergo (PDF)
|
||||
* 3 copies d'écrans (PNG)
|
||||
|
||||
A la boîte aux lettres pulvermuller@dept-info.u-strasbg.fr
|
||||
|
||||
OBJET : LPRO-Acrobatt Groupe ???
|
||||
CORPS : Noms des membres
|
||||
FICHIERS : Groupe5-CharteGrap ou Groupe5-CharteErgo, etc.
|
||||
|
||||
Il faut penser à faire une version papier, et à la fin de la réalisation, le professeur doit pouvoir jouer sur l'interface
|
||||
|
||||
====== SUITE CRITERES DE BASTIEN ======
|
||||
|
||||
===== Flexibilité =====
|
||||
|
||||
Application de meilleure ergonomie
|
||||
|
||||
* Flexibilité = Capacité de notre application, de nos interfaces à s'adapter à une population très variées d'utilisateurs
|
||||
* différents types d'utilisateurs
|
||||
* différentes stratégies d'utilisation
|
||||
* Procédures / Moyens différents pour atteindre le même objectif
|
||||
* Objectif : l'utilisateur choisit la procédure qui lui convient le mieux
|
||||
* Ex :
|
||||
* Accès par menu (débutants)
|
||||
* Par raccourcis clavier (experts)
|
||||
* Défauts utilisateur / Paramétrage
|
||||
|
||||
Paramétrage forcé : permettre à l'utilisateur __d'attribuer__ des raccourcis claviers à chacune des fonctions de l'application
|
||||
|
||||
Paramétrage possible : ensemble de fonctionnalités nommées MACRO !
|
||||
|
||||
Pour une population hétérogène, la flexibilité est TRES importante !
|
||||
|
||||
===== Contrôle explicite =====
|
||||
|
||||
* Moyens pour permettre à l'utilisateur de maîtriser / contrôler les traitements réalisés par le système
|
||||
* Les effets d'une commande doivent être prévisibles aux yeus de l'usager
|
||||
* Objectif : Meilleure compréhension du système (modèle mental exact)
|
||||
* Facteur important d'acceptation du système
|
||||
* Ex !
|
||||
* Valider explicitement les commandes importantes ou difficilement réversibles.
|
||||
* Sur un bouton, un menu, du texte, une icône, quand il y a trois petits points on sait d'avance qu'il y aura une boîte de dialogue !
|
||||
* Autoriser les interruptions
|
||||
* L'utilisateur doit toujours garder le contrôle des traitements en cours
|
||||
* Ex :
|
||||
* Prévoir des possibilités d'interruption
|
||||
* Autoriser les retours en arrière
|
||||
* Le rythme de saisie ne doit pas être imposé par le système
|
||||
* Laisser l'utilisateur choisir ses unités de mesures
|
||||
|
||||
===== Les erreurs =====
|
||||
|
||||
* Sort l'utilisateur de son processus métier
|
||||
* Fait perdre du temps, rallonge la tâche
|
||||
|
||||
Gestion des erreurs:
|
||||
* Prévoir que l'utilisateur fera des erreurs
|
||||
* Concevoir des moyens de pallier ce problème.
|
||||
* On doit pouvoir :
|
||||
* protéger l'utilisateur contre les erreurs : détection de la part du système (saisie dates, décimaux)
|
||||
* l'avertir lorsqu'il a commis une erreur que l'on peut détecter
|
||||
* corriger ou l'aider à corriger ses erreurs : guider l'utilisateur (étapes à suivre pour rectifier l'erreur)
|
||||
* Minimiser le risque d'erreur améliore l'utilisabilité du système
|
||||
|
||||
==== Erreurs perceptives ====
|
||||
|
||||
Ne pas faire la différence entre un i majuscule et un L minuscule => génère des erreurs
|
||||
|
||||
Solution : prendre une police de caractère avec empattement
|
||||
|
||||
* Rendre clairement visible les changements de mode et les états du système
|
||||
* etc.
|
||||
==== Erreurs cognitives ====
|
||||
|
||||
Dues à une réflexion ou une conclusion qui n'est pas bonne.
|
||||
|
||||
Ex: confision entre raccourcis et actions
|
||||
A. Create
|
||||
B. Delete
|
||||
C. Append
|
||||
D. Backup
|
||||
|
||||
Soluton :
|
||||
* Mettre en jeu la reconnaissance plus que le souvenir
|
||||
* Reconnaissance : choisir parmi plusieurs possibilités
|
||||
* Souvenir : Se rappeler de la valeur à saisir
|
||||
* La reconnaissance est moins sujette à l'erreur
|
||||
* Ex. Utilisation de menus, listes
|
||||
|
||||
==== Erreurs motrices ====
|
||||
|
||||
* Mouvements difficiles
|
||||
* F1 puis F12 : Déplacement de la main d'un bout à l'autre du clavier
|
||||
* Interaction "clavier, souris puis clavier"
|
||||
* Contraintes temporelles
|
||||
* Précisions sur [...]
|
||||
|
||||
Solutions:
|
||||
* Pas d'élément trop petit sur l'écran
|
||||
|
||||
|
||||
===== Comment gérer les erreurs ? =====
|
||||
|
||||
* 2 niveaux de protection : Prévention et Détection
|
||||
* Prévenir des erreurs en guidant l'utilisateur ("Guidage/ Incitation")
|
||||
* Détecter les erreurs au plus tôt => griser les boutons
|
||||
* Faciliter la correction des erreurs
|
||||
* Message d'erreur pertinent
|
||||
* Nature de l'erreur
|
||||
* Moyens de la corriger
|
||||
* Rendre possible la correction
|
||||
* Accès et modification partielle
|
||||
* Messages
|
||||
* Mettre en évidence le champ erroné
|
||||
* Placer le message d'erreur là où l'utilisateur est sensé regarder => exemple messages d'erreurs à CÔTÉ des erreurs (pour éviter le "scrolling").
|
||||
* Messages d'erreur explicites, brefs, non réprobateurs et auto - suffisants
|
||||
* Correction de l'erreur
|
||||
* Retour en arrière ("Undo")
|
||||
* Autoriser les interruptions pour les commandes longues
|
||||
* Permettre une modification partielle
|
||||
|
||||
==== Les messages d'erreurs ====
|
||||
|
||||
* Rendre le message d'erreur **instructif**
|
||||
* Les messages d'erreurs doivent toujours énoncer au moins
|
||||
* Quelle erreur a été détectée ?
|
||||
* Quel champ de saisie contient l'erreur ?
|
||||
* Quelle action correctrice doit être effectuée ?
|
||||
|
||||
Préférer :
|
||||
Le vol doit comporter la date AAAA/MM/JJ puis être suivi du code de l'aéroport XXX
|
||||
et
|
||||
Saisie: 20030515TOU
|
||||
|
||||
Préférer encore :
|
||||
Le vol doit....
|
||||
Ex : Vol du 15 avril 2003, Destination TOULON
|
||||
Saisie : 20030515TOU
|
||||
|
||||
Et encore:
|
||||
Le même message, mais avec des couleurs
|
||||
|
||||
===== Charge mentale =====
|
||||
|
||||
Globalement, sachant que nous ne sommes pas vraiment fourni en terme de mémorisation dans la mémoire immédiate, il ne faut pas demander à l'utilisateur de retenir quoi que ce soit.\\
|
||||
Il ne doit pas le faire à notre place !
|
||||
|
||||
Eviter les textes trop verbeux, etc ...
|
||||
|
||||
|
||||
===== GIU : Guide de l'Interface Utilisateur =====
|
||||
|
||||
Pas de rendu ou de look, pas d'image, mais on définit __les principes d'ergonomie__.
|
||||
|
||||
Comment faire pour demander à 5 développeurs pour qu'ils soient d'accord sur une forme d'action, les principes d'ergonomies, etc ...
|
||||
|
||||
Charte ergonomique = Liste de directives expliquant au concepteur comment concevoir un écran (menu à gauche, si en haut = fonctions transversales, si on a un fil d'ariane, etc.)\\
|
||||
Contient beaucoup de chapitres
|
||||
|
||||
Formats utilisés :
|
||||
* Disposition des éléments dans une IHM
|
||||
* Aligner les libellés (calés à gauche, espace, double point, puis champ de saisie, et finalement précision sur format attendu) => à utiliser le plus souvent possible
|
||||
* Calés à droite SI les libellés n'ont pas la même taille => Cas particulier
|
||||
* Disposition possible : en ligne, de haut en bas, libellé, puis champ de réponse, à nouveau libellé, champ, etc. => Colonne de navigation
|
||||
* Les saisies libres
|
||||
* Initialiser les champs de saisie (quand possible)
|
||||
* Valeur avec la plus grande probabilité d'être choisie
|
||||
* Valeur précédemment choisie
|
||||
* Différencier ce qui est obligatoire / facultatif => ce qui est aujourd'hui utilisé : Libellé du champ, double point, étoile rouge, puis champ de saisie => A METTRE DANS LA CHARTE D'ERGONOMIE
|
||||
* Les saisies à nombre limité d'options
|
||||
* Les radio-button => définir des règles (à partir de combien de choix faisons nous un menu déroulant ?)
|
||||
* Les cases à cocher
|
||||
* Les tableaux de données (et les listes)
|
||||
* Attribuer un titre aux listes
|
||||
* Respecter les alignements standards des traitements de texte :
|
||||
* Le texte en général à gauche
|
||||
* Les numériques à droite (attention aux décimales)
|
||||
* Éviter les alignements centrés (effets de vagues verticales)
|
||||
* Les menus
|
||||
* utiliser si possible un seul mot
|
||||
* Les couleurs
|
||||
* Dans la charte d'ergonomie dire : tout les champs qui sont en erreurs sont de fond rouge, focus par défaut, libellé d'erreur dessous (principe d'ergonomie, rouge = alerte), mais pas donner la couleur RGB (ça c'est charte graphique !)
|
||||
|
||||
__NB__ : La charte graphique est en deux :
|
||||
* D'une part la CSS (avec des RGB, etc ...)
|
||||
* D'autre part (et en premier lieu), la charte graphique elle même , avec, par exemple : input_error, input_error_border et input_error_msg
|
||||
|
||||
==== Navigation inductive ====
|
||||
|
||||
Dans charte d'ergonomie on doit définir la navigation intra - fenêtre :
|
||||
* Ex : "On préconise un maximum de cet onglet"
|
||||
* On peut mettre des onglets sur plusieurs niveaux, mais c'est pas bon (2 niveaux oui, 3 trop !!)
|
||||
* Bouton OK et ANNULER sont par exemple pour l'ensemble des onglets, et non pas pour un onglet en particulier
|
||||
* Un onglet est presque égal à un écran
|
||||
|
||||
* Les processus par étapes permettent d'effectuer dans un ordre prédéfini une activité complexe
|
||||
* Processus de type assisté "Wizard"
|
||||
* Nombre d'étapes : 4 à 6 selon les cas
|
||||
* Nom des étapes en haut et endroit où nous nous trouvons
|
||||
* Concentré de l'étape au milieu
|
||||
* En bas on peut aller à l'étape suivante ou précédente
|
||||
*
|
||||
|
||||
__NB__ : Dans la charte ergonomique, procéder par boîte "fil de fer" (des carrés grossiers) et donner un peu le principe de chaque boîte, etc ...
|
||||
|
||||
==== Navigation multi-fenêtrage ====
|
||||
|
||||
Une fenêtre appelle une autre fenêtre qui appelle une autre fenêtre, etc. => Profondeur de la navigation => doit être limité à 3 niveaux !!!
|
||||
|
||||
==== Aides à la navigation ====
|
||||
|
||||
* Lorsque la navigation est complexe, la mémoire à court terme est rapidement saturée (nombreux choix)
|
||||
* L'utilisateur a des difficultés à savoir où il est et par où il est passé
|
||||
* Fournir des moyens de guidage pour éviter à l'utilisateur de se "perdre"
|
||||
|
||||
====== Démonstration Caisse d'épargne ======
|
||||
|
||||
===== Charte d'ergonomie =====
|
||||
|
||||
Dans la charte d'ergonomie (environ 250 à 300 pages) il faut définir :
|
||||
* Le zoning de notre application => bandeau ici, navigation principale est rétractable, à cet endroit, j'ai une barre d'état, etc.
|
||||
* Définir les différents cas d'agencement des contenus
|
||||
* Conception de la structure
|
||||
* Groupement des rubriques
|
||||
* Ordre des rubriques
|
||||
* Si onglet : décrire avantages, inconvénients, conditions, cas particuliers, onglets versus boutons radios (servent à filtrer une information de nature unique alors que les onglets permettant d'afficher des morceaux d'une donné unique)
|
||||
* Processus à étapes logiques : fonction, usage, typographie, nombres d'étapes, contenu des étapes, étapes dynamiques (quand on dit qu'on prend la même adresse de livraison et de facturation => saisie de l'adresse de facturation est grisé, on saute l'étape), l'utilisateur doit pouvoir revenir sur une étape précédente
|
||||
* Comment se présente et s'architecture un processus à étape
|
||||
* Quand on dépasse 6 étapes : on fait 5/10, et on affiche un fil d'ariane des étapes, et on mets au centre le libellé de l'étape sur laquelle nous sommes
|
||||
* Libellés des boutons d'actions : dire dans quel cas ils sont utilisés, et les formulaires qui pourraient les utiliser => faire un inventaire des boutons qui pourraient répondre à l'ensemble des actions dans 95% des cas
|
||||
* Donner la règle à respecter pour les formulations de boutons :
|
||||
* Verbe à l'infinitif : souscrire
|
||||
* VB à l'INF. + Substantif : ajouter un RIB
|
||||
* Substantif seul : Créer un nouveau rendez vous
|
||||
* Etat des boutons : Normal, Séléctionné, Inactif, Critique (juste dire qu'ils seront différents, pas donner les couleurs)
|
||||
* Les boutons critiques doivent être séparés des autres boutons (définition de grands principes)
|
||||
* Pour les champs de saisie, idem
|
||||
|
||||
===== Charte graphique =====
|
||||
|
||||
FAIRE UNE CSS pour l'aperçu avant impression !
|
||||
|
||||
* On définit un gabaris des couleurs permises !
|
||||
* Explication ce qui va se passer au niveau des CSS (principe qu'on utilise)
|
||||
* Pour chaque élément, donner : rangée impaire, tr.impair et pas les couleurs pour chaque truc ! Il faut donner les noms à utiliser ! Toute façon le "dessinateur" Web passera derrière !
|
||||
|
||||
Document PowerPoint, avec le nom des classes qui ciblent sur des éléments d'une image PNG (photoshop ou autre).
|
||||
|
||||
Faire un index visuel : le nom du style qui prend la forme du style !
|
||||
|
||||
|
255
A62/Cours2~
Normal file
255
A62/Cours2~
Normal file
@ -0,0 +1,255 @@
|
||||
A62, 27 mars 2008
|
||||
|
||||
Pour le 9 mai 2008 :
|
||||
* Charte graphique (PDF) => pas de PDF de plus de 10Mo !
|
||||
* Charte ergo (PDF)
|
||||
* 3 copies d'écrans (PNG)
|
||||
|
||||
A la boîte aux lettres pulvermuller@dept-info.u-strasbg.fr
|
||||
|
||||
OBJET : LPRO-Acrobatt Groupe ???
|
||||
CORPS : Noms des membres
|
||||
FICHIERS : Groupe5-CharteGrap ou Groupe5-CharteErgo, etc.
|
||||
|
||||
Il faut penser à faire une version papier, et à la fin de la réalisation, le professeur doit pouvoir jouer sur l'interface
|
||||
|
||||
== SUITE CRITERES DE BASTIEN ==
|
||||
|
||||
=== Flexibilité ===
|
||||
|
||||
Application de meilleure ergonomie
|
||||
|
||||
* Flexibilité = Capacité de notre application, de nos interfaces à s'adapter à une population très variées d'utilisateurs
|
||||
* différents types d'utilisateurs
|
||||
* différentes stratégies d'utilisation
|
||||
* Procédures / Moyens différents pour atteindre le même objectif
|
||||
* Objectif : l'utilisateur choisit la procédure qui lui convient le mieux
|
||||
* Ex :
|
||||
* Accès par menu (débutants)
|
||||
* Par raccourcis clavier (experts)
|
||||
* Défauts utilisateur / Paramétrage
|
||||
|
||||
Paramétrage forcé : permettre à l'utilisateur __d'attribuer__ des raccourcis claviers à chacune des fonctions de l'application
|
||||
|
||||
Paramétrage possible : ensemble de fonctionnalités nommées MACRO !
|
||||
|
||||
Pour une population hétérogène, la flexibilité est TRES importante !
|
||||
|
||||
=== Contrôle explicite ===
|
||||
|
||||
* Moyens pour permettre à l'utilisateur de maîtriser / contrôler les traitements réalisés par le système
|
||||
* Les effets d'une commande doivent être prévisibles aux yeus de l'usager
|
||||
* Objectif : Meilleure compréhension du système (modèle mental exact)
|
||||
* Facteur important d'acceptation du système
|
||||
* Ex !
|
||||
* Valider explicitement les commandes importantes ou difficilement réversibles.
|
||||
* Sur un bouton, un menu, du texte, une icône, quand il y a trois petits points on sait d'avance qu'il y aura une boîte de dialogue !
|
||||
* Autoriser les interruptions
|
||||
* L'utilisateur doit toujours garder le contrôle des traitements en cours
|
||||
* Ex :
|
||||
* Prévoir des possibilités d'interruption
|
||||
* Autoriser les retours en arrière
|
||||
* Le rythme de saisie ne doit pas être imposé par le système
|
||||
* Laisser l'utilisateur choisir ses unités de mesures
|
||||
|
||||
=== Les erreurs ==
|
||||
|
||||
* Sort l'utilisateur de son processus métier
|
||||
* Fait perdre du temps, rallonge la tâche
|
||||
|
||||
Gestion des erreurs:
|
||||
* Prévoir que l'utilisateur fera des erreurs
|
||||
* Concevoir des moyens de pallier ce problème.
|
||||
* On doit pouvoir :
|
||||
* protéger l'utilisateur contre les erreurs : détection de la part du système (saisie dates, décimaux)
|
||||
* l'avertir lorsqu'il a commis une erreur que l'on peut détecter
|
||||
* corriger ou l'aider à corriger ses erreurs : guider l'utilisateur (étapes à suivre pour rectifier l'erreur)
|
||||
* Minimiser le risque d'erreur améliore l'utilisabilité du système
|
||||
|
||||
==== Erreurs perceptives ====
|
||||
|
||||
Ne pas faire la différence entre un i majuscule et un L minuscule => génère des erreurs
|
||||
|
||||
Solution : prendre une police de caractère avec empattement
|
||||
|
||||
* Rendre clairement visible les changements de mode et les états du système
|
||||
* etc.
|
||||
==== Erreurs cognitives ====
|
||||
|
||||
Dues à une réflexion ou une conclusion qui n'est pas bonne.
|
||||
|
||||
Ex: confision entre raccourcis et actions
|
||||
A. Create
|
||||
B. Delete
|
||||
C. Append
|
||||
D. Backup
|
||||
|
||||
Soluton :
|
||||
* Mettre en jeu la reconnaissance plus que le souvenir
|
||||
* Reconnaissance : choisir parmi plusieurs possibilités
|
||||
* Souvenir : Se rappeler de la valeur à saisir
|
||||
* La reconnaissance est moins sujette à l'erreur
|
||||
* Ex. Utilisation de menus, listes
|
||||
|
||||
==== Erreurs motrices ====
|
||||
|
||||
* Mouvements difficiles
|
||||
* F1 puis F12 : Déplacement de la main d'un bout à l'autre du clavier
|
||||
* Interaction "clavier, souris puis clavier"
|
||||
* Contraintes temporelles
|
||||
* Précisions sur [...]
|
||||
|
||||
Solutions:
|
||||
* Pas d'élément trop petit sur l'écran
|
||||
|
||||
|
||||
=== Comment gérer les erreurs ? ===
|
||||
|
||||
* 2 niveaux de protection : Prévention et Détection
|
||||
* Prévenir des erreurs en guidant l'utilisateur ("Guidage/ Incitation")
|
||||
* Détecter les erreurs au plus tôt => griser les boutons
|
||||
* Faciliter la correction des erreurs
|
||||
* Message d'erreur pertinent
|
||||
* Nature de l'erreur
|
||||
* Moyens de la corriger
|
||||
* Rendre possible la correction
|
||||
* Accès et modification partielle
|
||||
* Messages
|
||||
* Mettre en évidence le champ erroné
|
||||
* Placer le message d'erreur là où l'utilisateur est sensé regarder => exemple messages d'erreurs à CÔTÉ des erreurs (pour éviter le "scrolling").
|
||||
* Messages d'erreur explicites, brefs, non réprobateurs et auto - suffisants
|
||||
* Correction de l'erreur
|
||||
* Retour en arrière ("Undo")
|
||||
* Autoriser les interruptions pour les commandes longues
|
||||
* Permettre une modification partielle
|
||||
|
||||
==== Les messages d'erreurs ====
|
||||
|
||||
* Rendre le message d'erreur **instructif**
|
||||
* Les messages d'erreurs doivent toujours énoncer au moins
|
||||
* Quelle erreur a été détectée ?
|
||||
* Quel champ de saisie contient l'erreur ?
|
||||
* Quelle action correctrice doit être effectuée ?
|
||||
|
||||
Préférer :
|
||||
Le vol doit comporter la date AAAA/MM/JJ puis être suivi du code de l'aéroport XXX
|
||||
et
|
||||
Saisie: 20030515TOU
|
||||
|
||||
Préférer encore :
|
||||
Le vol doit....
|
||||
Ex : Vol du 15 avril 2003, Destination TOULON
|
||||
Saisie : 20030515TOU
|
||||
|
||||
Et encore:
|
||||
Le même message, mais avec des couleurs
|
||||
|
||||
=== Charge mentale ===
|
||||
|
||||
Globalement, sachant que nous ne sommes pas vraiment fourni en terme de mémorisation dans la mémoire immédiate, il ne faut pas demander à l'utilisateur de retenir quoi que ce soit.\\
|
||||
Il ne doit pas le faire à notre place !
|
||||
|
||||
Eviter les textes trop verbeux, etc ...
|
||||
|
||||
|
||||
=== GIU : Guide de l'Interface Utilisateur ===
|
||||
|
||||
Pas de rendu ou de look, pas d'image, mais on définit __les principes d'ergonomie__.
|
||||
|
||||
Comment faire pour demander à 5 développeurs pour qu'ils soient d'accord sur une forme d'action, les principes d'ergonomies, etc ...
|
||||
|
||||
Charte ergonomique = Liste de directives expliquant au concepteur comment concevoir un écran (menu à gauche, si en haut = fonctions transversales, si on a un fil d'ariane, etc.)\\
|
||||
Contient beaucoup de chapitres
|
||||
|
||||
Formats utilisés :
|
||||
* Disposition des éléments dans une IHM
|
||||
* Aligner les libellés (calés à gauche, espace, double point, puis champ de saisie, et finalement précision sur format attendu) => à utiliser le plus souvent possible
|
||||
* Calés à droite SI les libellés n'ont pas la même taille => Cas particulier
|
||||
* Disposition possible : en ligne, de haut en bas, libellé, puis champ de réponse, à nouveau libellé, champ, etc. => Colonne de navigation
|
||||
* Les saisies libres
|
||||
* Initialiser les champs de saisie (quand possible)
|
||||
* Valeur avec la plus grande probabilité d'être choisie
|
||||
* Valeur précédemment choisie
|
||||
* Différencier ce qui est obligatoire / facultatif => ce qui est aujourd'hui utilisé : Libellé du champ, double point, étoile rouge, puis champ de saisie => A METTRE DANS LA CHARTE D'ERGONOMIE
|
||||
* Les saisies à nombre limité d'options
|
||||
* Les radio-button => définir des règles (à partir de combien de choix faisons nous un menu déroulant ?)
|
||||
* Les cases à cocher
|
||||
* Les tableaux de données (et les listes)
|
||||
* Attribuer un titre aux listes
|
||||
* Respecter les alignements standards des traitements de texte :
|
||||
* Le texte en général à gauche
|
||||
* Les numériques à droite (attention aux décimales)
|
||||
* Éviter les alignements centrés (effets de vagues verticales)
|
||||
* Les menus
|
||||
* utiliser si possible un seul mot
|
||||
* Les couleurs
|
||||
* Dans la charte d'ergonomie dire : tout les champs qui sont en erreurs sont de fond rouge, focus par défaut, libellé d'erreur dessous (principe d'ergonomie, rouge = alerte), mais pas donner la couleur RGB (ça c'est charte graphique !)
|
||||
|
||||
__NB__ : La charte graphique est en deux :
|
||||
* D'une part la CSS (avec des RGB, etc ...)
|
||||
* D'autre part (et en premier lieu), la charte graphique elle même , avec, par exemple : input_error, input_error_border et input_error_msg
|
||||
|
||||
==== Navigation inductive ====
|
||||
|
||||
Dans charte d'ergonomie on doit définir la navigation intra - fenêtre :
|
||||
* Ex : "On préconise un maximum de cet onglet"
|
||||
* On peut mettre des onglets sur plusieurs niveaux, mais c'est pas bon (2 niveaux oui, 3 trop !!)
|
||||
* Bouton OK et ANNULER sont par exemple pour l'ensemble des onglets, et non pas pour un onglet en particulier
|
||||
* Un onglet est presque égal à un écran
|
||||
|
||||
* Les processus par étapes permettent d'effectuer dans un ordre prédéfini une activité complexe
|
||||
* Processus de type assisté "Wizard"
|
||||
* Nombre d'étapes : 4 à 6 selon les cas
|
||||
* Nom des étapes en haut et endroit où nous nous trouvons
|
||||
* Concentré de l'étape au milieu
|
||||
* En bas on peut aller à l'étape suivante ou précédente
|
||||
*
|
||||
|
||||
__NB__ : Dans la charte ergonomique, procéder par boîte "fil de fer" (des carrés grossiers) et donner un peu le principe de chaque boîte, etc ...
|
||||
|
||||
==== Navigation multi-fenêtrage ====
|
||||
|
||||
Une fenêtre appelle une autre fenêtre qui appelle une autre fenêtre, etc. => Profondeur de la navigation => doit être limité à 3 niveaux !!!
|
||||
|
||||
==== Aides à la navigation ====
|
||||
|
||||
* Lorsque la navigation est complexe, la mémoire à court terme est rapidement saturée (nombreux choix)
|
||||
* L'utilisateur a des difficultés à savoir où il est et par où il est passé
|
||||
* Fournir des moyens de guidage pour éviter à l'utilisateur de se "perdre"
|
||||
|
||||
== Démonstration Caisse d'épargne ==
|
||||
|
||||
=== Charte d'ergonomie ===
|
||||
|
||||
Dans la charte d'ergonomie (environ 250 à 300 pages) il faut définir :
|
||||
* Le zoning de notre application => bandeau ici, navigation principale est rétractable, à cet endroit, j'ai une barre d'état, etc.
|
||||
* Définir les différents cas d'agencement des contenus
|
||||
* Conception de la structure
|
||||
* Groupement des rubriques
|
||||
* Ordre des rubriques
|
||||
* Si onglet : décrire avantages, inconvénients, conditions, cas particuliers, onglets versus boutons radios (servent à filtrer une information de nature unique alors que les onglets permettant d'afficher des morceaux d'une donné unique)
|
||||
* Processus à étapes logiques : fonction, usage, typographie, nombres d'étapes, contenu des étapes, étapes dynamiques (quand on dit qu'on prend la même adresse de livraison et de facturation => saisie de l'adresse de facturation est grisé, on saute l'étape), l'utilisateur doit pouvoir revenir sur une étape précédente
|
||||
* Comment se présente et s'architecture un processus à étape
|
||||
* Quand on dépasse 6 étapes : on fait 5/10, et on affiche un fil d'ariane des étapes, et on mets au centre le libellé de l'étape sur laquelle nous sommes
|
||||
* Libellés des boutons d'actions : dire dans quel cas ils sont utilisés, et les formulaires qui pourraient les utiliser => faire un inventaire des boutons qui pourraient répondre à l'ensemble des actions dans 95% des cas
|
||||
* Donner la règle à respecter pour les formulations de boutons :
|
||||
* Verbe à l'infinitif : souscrire
|
||||
* VB à l'INF. + Substantif : ajouter un RIB
|
||||
* Substantif seul : Créer un nouveau rendez vous
|
||||
* Etat des boutons : Normal, Séléctionné, Inactif, Critique (juste dire qu'ils seront différents, pas donner les couleurs)
|
||||
* Les boutons critiques doivent être séparés des autres boutons (définition de grands principes)
|
||||
* Pour les champs de saisie, idem
|
||||
|
||||
=== Charte graphique ===
|
||||
|
||||
FAIRE UNE CSS pour l'aperçu avant impression !
|
||||
|
||||
* On définit un gabaris des couleurs permises !
|
||||
* Explication ce qui va se passer au niveau des CSS (principe qu'on utilise)
|
||||
* Pour chaque élément, donner : rangée impaire, tr.impair et pas les couleurs pour chaque truc ! Il faut donner les noms à utiliser ! Toute façon le "dessinateur" Web passera derrière !
|
||||
|
||||
Document PowerPoint, avec le nom des classes qui ciblent sur des éléments d'une image PNG (photoshop ou autre).
|
||||
|
||||
Faire un index visuel : le nom du style qui prend la forme du style !
|
||||
|
||||
|
44
A63/Seance1
Normal file
44
A63/Seance1
Normal file
@ -0,0 +1,44 @@
|
||||
Quand on éteind le pc, on perd souvent les données contenues dans un programme.
|
||||
voilà pourquoi il est utile de sauver le travail dans des fichiers, des bases, etc ...
|
||||
D'où l'existence de la persistance des données.
|
||||
|
||||
Oracle Toplink JPA sera utilisé pendant les cours, mais nous utiliserons la partie libre de cette implémentation.
|
||||
Il est plus intéressant d'utiliser des librairies et ce avec Toplink.
|
||||
|
||||
Une base de données est relationnelle, contrairement à nos objets, voilà pourquoi nous devons permettre l'insertion correcte de nos objets dans une base de données relationelle.
|
||||
Idée de persistance : on retrouve tout nos objets avec les éventuelles modifications apportées entre temps.
|
||||
|
||||
Mapping, en français se dit, d'aprÚs le professeur, **mappage** !
|
||||
|
||||
JPA = Java Programmaing API (API = Application Programming Interface)
|
||||
JDO = Java Database Object
|
||||
C'est la norme de Sun.
|
||||
Hybernet était trÚs utilisée avant la norme JDO. Donc Sun a pris le meilleur de JDO et le meilleur d'Hybernet, et en a fait une nouvelle norme.
|
||||
Les nouvelles normes sont moins restrictives qu'avant.
|
||||
Au début avant JDO, la norme était JPOX. La bibliothÚque de référence est donc Oracle.
|
||||
|
||||
===== JavaBean =====
|
||||
|
||||
Quand nous créeons un objet Java Bean, nous ajoutons des sortes de commentaires qui vont informer que tel ou tel ascesseurs / mutateurs vont correspondre à telle ou telle colonne / table dans la base de données.
|
||||
Par défaut cela prend les gets/sets de la classe Java Bean, cependant il faut préciser :
|
||||
* Correspondance un à plusieurs
|
||||
* Colone de la clé étrangÚre
|
||||
|
||||
Il faut aussi un EM (= entity manager).
|
||||
|
||||
===== Persistance =====
|
||||
|
||||
Même aprÚs avoir utilisé un EM, et aprÚs avoir demandé les informations de l'objet, on sauve l'objet à l'aide de la méthode **persistent**.
|
||||
Tout va être enregistré dans la base de données ! Cependant il faut demander à enregistrer les données, donc il faut toujours faire un persistant.
|
||||
|
||||
===== Transactions =====
|
||||
|
||||
Ne pas oublier de mettre le tout dans une transaction, elle même dans un contexte. Il faut donc le code associé.
|
||||
Une transaction est une opération qui nécessite plusieurs actions, actions qui ne PEUVENT être séparées.
|
||||
Exemple : un virement interne est une action de débit et une action de crédit. Il faut donc que les deux soient faites ou pas du tout, aprÚs plantage c'est soit l'un, soit l'autre.
|
||||
|
||||
===== Agent Java =====
|
||||
|
||||
L'agent java, ou //javaagent// va triturer le code, va **instrumentaliser** le code binaire de notre fichier Java pour permettre d'ajouter les choses nécessaire pour JDBC.
|
||||
|
||||
|
472
A63/XML-Introduction
Normal file
472
A63/XML-Introduction
Normal file
@ -0,0 +1,472 @@
|
||||
====== A63 : Peristance des bases de données ======
|
||||
|
||||
===== Définitions de balises =====
|
||||
|
||||
===== SGML =====
|
||||
|
||||
A la fin des années 1960, Charles GOLDFOND, Edward MOSHER et Raymond LORIE (IBM) construisent un système puissant et portable pour interchanger et manopuler des documents légaux -> utilisation d'un langage de balises
|
||||
Le langage informait de la nature abstraite des informations plutôt que leur mise en page.
|
||||
Les informations de mise en page était spécifiée dans un format appelé feuille de style.
|
||||
|
||||
L'équipe d'IBM décida également de mettre en place un système capable de rejeter des documents invalides (documents avec des informations manquantes ou en surplus) La structure de chaque type de documents fût alors strictement définie dans un efichier appelé DTD (Document Type Definition).
|
||||
|
||||
1969: GML (Generaliszed Markup Language)\\
|
||||
1974: SGML (Standard Generalized Markup Language)
|
||||
|
||||
HTML + CSS (Cascading Style Sheet) crée par le W3C (World Wide Web Consortium)
|
||||
|
||||
XML proposé par le W3C combine la puissance et l'extensibilité de son ancêtre SGML et la simplicité imposées par la communauté du Web.
|
||||
|
||||
Principes :\\
|
||||
* permet de créer des langages de balises pour décrire n'importe quel type de document et appartenant à n'importe quel type de domaine d'une manière structurée : hiérarchique
|
||||
* permet de créer de nouvelles balises
|
||||
|
||||
Analyse de document XML :\\
|
||||
* Lire le document
|
||||
* Contrôle de la syntaxe
|
||||
* Indique les erreurs
|
||||
|
||||
Syntaxe : \\
|
||||
* Un seul élément racine
|
||||
* Chaque élément doit avoir une balise de début et de fin
|
||||
* Les balises doivent être correctement imbriquées
|
||||
* La valeur des attributs doivent être entre guillemets
|
||||
* XML fait la différence entre les majuscules et les minuscules
|
||||
|
||||
=> Un docupment syntaxiquement correct et dit bien formé !
|
||||
|
||||
===== Les caractères autorisées =====
|
||||
|
||||
On différencie : \\
|
||||
* les caractères contenus dans les balises (nom d'élément et d'attributs)
|
||||
* les caractères de données (contenues entre deux balises)
|
||||
|
||||
Certains caractères blancs seront significatifs et d'autres pas.\\
|
||||
Ex : <code xml><balise>C'est un caractère de _ _ _ _ _ données</balise></code>
|
||||
|
||||
On n'utilisera pas d'espaces dans les noms d'éléments et d'attributs.
|
||||
|
||||
Références d'entité et entités prédéfinies : \\
|
||||
&xxx;\\
|
||||
& (&)\\
|
||||
<(<)\\
|
||||
> (>)\\
|
||||
' (')\\
|
||||
"(")
|
||||
|
||||
===== Les balises =====
|
||||
|
||||
==== Définition ====
|
||||
|
||||
Un élément défninit une structure, il peut avoir ou ne pas avoir de contenu (élément fils et des caractères de données). Aucun, un à plusieurs attributs peuvent lui être associés.
|
||||
|
||||
==== Définition 2 ====
|
||||
|
||||
Un attribut décrit un élément. Il sera placé à l'intérieur de la balise de départ d'un élément. La valeur d'un attribut est entourée d'apostrophes.
|
||||
<code xml><voiture porte='4' /></code>. Ceci est un élément sans caractères de données.
|
||||
|
||||
La section CDATA n'est pas traitée par l'analyse XML. Elle peut contenir du texte, des caractères reservées et des espaces. elle est souvent utilisée pour contenir du code script :
|
||||
<code xml><![CDATA[ _ _ _ ]]></code>
|
||||
|
||||
===== Les espaces de nom =====
|
||||
|
||||
La notion d'espace de nom permet d'éviter les collisions de nom.
|
||||
|
||||
Ex: <code xml><sujet>Math</sujet>
|
||||
<sujet>electro encephalographie</sujet>
|
||||
</code>
|
||||
|
||||
Ces deux éléments sujet peuvent être différenciés par des espaces de nom.
|
||||
|
||||
<code xml><ecole:sujet>Math</ecole:sujet>
|
||||
<medecine:sujet>electro encephalographie</medecine:sujet></code>
|
||||
|
||||
Chaque préfixe d'espace de nom est associé à un identificateur de ressource uniforme (URI) qui identifie de façon unique un espace de nom.\\
|
||||
Pour être sûr que l'espace de nom est unique, une méthode consiste à utiliser les URL (Universal Resources Locators). Car les noms de domaines sont toujours uniques.
|
||||
|
||||
===== Avantages de XML =====
|
||||
|
||||
Intérêt de XML : pas toujours besoin de faire des requêtes sur le serveur, le client peut s'en occuper.
|
||||
|
||||
|
||||
====== Les DTD (Document Type Definition) ======
|
||||
|
||||
===== Définition =====
|
||||
|
||||
Définit la structure d'un document XML => valide sa conformité.\\
|
||||
Une DTD est définie en utilisant la grammaire EBNF (Extended Backus-Naur Form)\\
|
||||
Un document XML conforme à une DTD est dit __valide__.\\
|
||||
Un analyseur validant (Ex: Validant XML Microsoft) permet de dire si un document XML est valide ou non.
|
||||
|
||||
===== Déclaration de document type =====
|
||||
|
||||
<code xml><!DOCTYPE nomRacine ></code>
|
||||
|
||||
La DTD peut être soit interne soit externe.
|
||||
|
||||
Déclaration interne :
|
||||
<code xml><!DOCTYPE monMessage[
|
||||
<!ELEMENT monMessage(#PCDATA)>
|
||||
]></code>
|
||||
|
||||
<code xml><!DOCTYPE monMessage SYSTEM "maDTD.dtd"
|
||||
[<!ELEMENT monElement (#PCDATA)>
|
||||
]></code>
|
||||
|
||||
Exemple :
|
||||
<code xml><!DOCTYPE html PUBLIC "http://www.w3.org/TR/html4/strict.dtd"></code>
|
||||
|
||||
===== Déclaration d'élements Type =====
|
||||
|
||||
Un élément est un bloc de base d'un document XML.
|
||||
|
||||
<code XML>
|
||||
<!ELEMENT monelement (#PCDATA)>
|
||||
</code>
|
||||
|
||||
PCDATA est la spécification du contenu, et //monelement// est le nom de l'élément.\\
|
||||
PCDATA veut, ici, signifier que l'élément contient des caractères de données.
|
||||
|
||||
La DTD permet de définir l'ordre et la fréquence des éléments fils
|
||||
* Les séquences sont indiquées avec '**,**'
|
||||
<code xml>
|
||||
<!ELEMENT classe (professeur, étudiant)>
|
||||
</code>
|
||||
* Exactement 1 professeur et 1 étudiant dans cet ordre.
|
||||
* Les choix indiqués par '**|**'
|
||||
Exemple : <code xml>
|
||||
<!ELEMENT dessert (glace | pâtisserie )>
|
||||
</code>
|
||||
* Contient soit une glace soit une pâtisserie, mais pas les deux indicateurs d'occurences
|
||||
<code xml>
|
||||
<!ELEMENT album (chanson+)> : Une occurence ou plus
|
||||
<!ELEMENT album (titre, (titre-chanson,durée)+)> : On devra spécifier une fois au MINIMUM titre-chanson.
|
||||
<!ELEMENT bibliothèque (livre*)> : On peut répéter autant de fois livre qu'on veut dans bibliothèque.
|
||||
<!ELEMENT choix (personne?)> : L'élément choix pourra avoir un élément personne ou pas.
|
||||
</code>
|
||||
|
||||
Voici un exemple plus complet :
|
||||
<code xml>
|
||||
<!ELEMENT ferme (fermier+, (chien*|chat?), cochon*, (chèvre|vache)?, (poulet+|canard*))>
|
||||
</code>
|
||||
|
||||
Ceci donnera :
|
||||
|
||||
<code xml>
|
||||
<ferme>
|
||||
<fermier>Jeanne Dupond</fermier>
|
||||
<fermier>Jean Dupond</fermier>
|
||||
<chat>ponpon</chat>
|
||||
<cochon>tire-bouchon</cochon>
|
||||
<poulet>cocotte</poulet>
|
||||
</ferme>
|
||||
</code>
|
||||
|
||||
===== Déclaration d'attributs =====
|
||||
|
||||
S'effectue avec le mot clé //ATTLIST//
|
||||
<code xml>
|
||||
<!ELEMENT x EMPTY>
|
||||
<!ATTLIST x y CDATA #REQUIRED>
|
||||
</code>
|
||||
|
||||
EMPTY est l'élément vide.\\
|
||||
x : nom de l'élément
|
||||
y : nom de l'attribut
|
||||
CDATA : contenu de l'attribut
|
||||
#REQUIRED : utilisation de l'attribut
|
||||
|
||||
Attributs par défaut : #REQUIRED, #IMPLIED, #FIXED.
|
||||
* #REQUIRED : doit être défini
|
||||
* #IMPLIED : Si l'attribut n'apparaît pas dans l'élément XML peut utiliser n'importe quelle valeur.
|
||||
* #FIXED : la valeur de l'attribut est une constante et ne peut pas être autre chose dans le document
|
||||
<code xml>
|
||||
<!ATTLIST adresse code_postal #FIXED "67730">
|
||||
</code>
|
||||
|
||||
===== Types d'attributs =====
|
||||
|
||||
Il y a 3 types différents d'attributs :
|
||||
* les chaînes (CDATA)
|
||||
* les attributs à jeton
|
||||
* les attributs énumérés
|
||||
|
||||
==== Attributs à jeton ====
|
||||
|
||||
* ID : Identifie de manière unique un élément. XML demande apparemment (expérience de la prof) un caractère alphanumérique d'abord ! Exemple : s1
|
||||
* IDREF : pointe sur un élément ayant un attribut ID. Vérifie si il existe dans le document un élément avec un attribut ID dont la valeur correspond à la valeur de l'attribut IDREF.
|
||||
* NMTOKEN (peu usité) : la valeur ne doit être constituée que de lettres, de chiffres, de tirets (-), de soulignés (_), de deux points (:) et de points (.)
|
||||
|
||||
==== Le type énuméré ====
|
||||
|
||||
Déclare une liste de valeurs possibles pour l'attribut. Ces valeurs sont séparées dans la définition par un '**|**'.
|
||||
<code xml>
|
||||
<!ATTLIST personne genre (M|F) "F">
|
||||
</code>
|
||||
|
||||
==== Les sections conditionnelles ====
|
||||
|
||||
Une DTD permet d'inclure ou d'exlure des déclarations en utilisant des sections conditionnelles.
|
||||
<code xml>
|
||||
<![INCLUDE[ _ _ _ _ _]]> : donne la directive d'inclure l'élément
|
||||
<![INGNORE[ _ _ _ _ _]]> : donne la directive d'ignorer l'élément
|
||||
</code>
|
||||
|
||||
===== Traitement des espaces dans les DTD =====
|
||||
|
||||
* les attributs de type CDATA respectent les espaces
|
||||
* les attributs à jeton (ID, IDREF, NMTOKEN) suppriment les espaces
|
||||
* les attributs de type énuméré suppriment les espaces (normalisation)
|
||||
|
||||
====== Les schémas ======
|
||||
|
||||
Les schémas étudiés ici respectent le standard W3C (World Wide Web Consortium).\\
|
||||
* Le but d'un schéma est de spécifier une structure de document XML.
|
||||
* Utilise la même syntaxe que celle utilisée dans un document XML
|
||||
* Possède plus de possibilités de spécifications que les DTD
|
||||
|
||||
Dans les schémas XML le contenu d'un élément est défini par son nom et son type.\\
|
||||
On distingue les types simples et les types complexes.\\
|
||||
Des types simples sont prédéfinis.\\
|
||||
Ex: String, Integer, decimal\\
|
||||
Un type simple ne peut pas contenir d'éléments fils ou d'attributs.
|
||||
|
||||
Un type complexe peut spécifier des éléments fils et des attributs associés.\\
|
||||
Les éléments peuvent être constitués d'éléments préalablement définis en utilisant les concepts d'agrégation et d'héritage.
|
||||
|
||||
* Agrégation : permet de regrouper un ensemble d'élements à l'intérieur d'un nouvel élément
|
||||
* Héritage : permet d'étendre la définition d'un élément préalablement défini
|
||||
|
||||
----
|
||||
Vendredi 28 mars 2008
|
||||
|
||||
===== Éléments simples =====
|
||||
|
||||
Un élément peut être de type simple ou de type complexe. Le type simple ne peut pas définir de sous - éléments et d'attributs.
|
||||
|
||||
Un type simple peut être référencé depuis l'attribut type des éléments xsd:element et xsd.attribute.
|
||||
|
||||
Un élément xsd:element ou un élément xsd.attribute peut avoir un sous - élément xsd:simpleType sans attribut name définissant ainsi un type anonyme pour cet élément ou cet attribut.
|
||||
|
||||
Des nouveaux types peuvent être dérivés à partir de types existants d'une des 3 façons suivantes :
|
||||
* en restreignant l'intervalle du type de base en utilisant l'élément xsd:restriction
|
||||
* en combinant plusieurs types de base avec l'élement xsd:union.
|
||||
* en autorisant différentes valeurs d'un type de base séparé par un espace avec l'élément xsd:list
|
||||
|
||||
==== Facettes ====
|
||||
|
||||
Les éléments minExclusives, minInclusive... pattern sont appelés des facettes. Elles désignent un aspect d'une valeur possible pour un type simple.
|
||||
|
||||
La facette //pattern// peut désigner des restrictions très sophistiquées sur le format des chaînes de caractères. La facette pattern compare la valeur concernée par rapport à une expression régulière.
|
||||
|
||||
<code xml>
|
||||
<xsd:simpleType name="nss">
|
||||
<xsd:restriction base="xsd:string">
|
||||
<xsd:pattern value="\d\d\d_\d\d_\d\d\d\" />
|
||||
</xsd:restriction>
|
||||
</xsd:simpleType>
|
||||
</code>
|
||||
|
||||
===== Éléments complexe =====
|
||||
|
||||
Les types complexes permettent de définir des sous - éléments et des attributs. Ils peuvent avoir un contennu simple (simpleContent) ou un contenu complexe (complexContent).
|
||||
|
||||
Seuls les éléments peuvent avoir des types complexes. Les attributs sont toujours de type simple.
|
||||
|
||||
Les mauvais types sont définis en utilisant les éléments xsd:complexType.
|
||||
|
||||
L'attribut mixed, s'il possède la valeur vraie, signifie que de l'élément peut avoir à la fois des caractères de données et des éléments fils.
|
||||
|
||||
==== Notion de contenu simple ====
|
||||
|
||||
L'élément xsd:simpleContent est utilisé dans les éléments xsd:complexType dont le contenu est un type simple. Cet élément sert particulièrement lorsque la seule raison pour laquelle un élément ait un type complexe est la définition d'attributs.
|
||||
|
||||
==== Contenu complexe ====
|
||||
|
||||
L'élément xsd:complexContent est utilisé dans les éléments xsd:complexType pour dériver de nouveaux types complexes à partir d'un type complexe existant par extension ou par restriction.
|
||||
|
||||
Lors de la dérivation par extension, l'attribut //mixed// doit avoir la même valeur que l'attribut mixed du type de base. Lors de la dérivation par restriction l'attribut mixed peut avoir la valeur false pour interdire un contenu mixte qui pourrait être utilisé dans le type de base.
|
||||
|
||||
=== Notion de contenu complexe ===
|
||||
|
||||
* L'élément xsd:sequence : indique que les éléments représentés par leur sous - éléments doivent apparaître dans le document dans l'ordre où ils ont été listés.
|
||||
* L'élément xsd:choice : précise que tous les éléments ou groupes représentés par un de ses sous - éléments __peut__ apparaître.
|
||||
* L'élément xsd:all indique que chaque élément représenté par un de ses sous - éléments xsd:element doit être présent. Cependant l'ordre n'a pas d'importance.
|
||||
|
||||
Dans la pratique, les plus utilisés sont //sequence// et //choice//.
|
||||
|
||||
===== Concept de base : déclaration d'attributs =====
|
||||
|
||||
xsd:attribute
|
||||
|
||||
L'attribut **use** peut avoir l'une des 3 valeurs suivantes :
|
||||
* optional : l'attribut est optionnel
|
||||
* prohibited : l'attribut ne doit pas apparaître
|
||||
* required : l'attribut doit apparaître
|
||||
|
||||
====== XML Path Language (XPath) ======
|
||||
|
||||
Préalable à la création de feuilles de style.
|
||||
|
||||
Permet de se balader dans un document XML, et pour aller à tel ou tel endroit du document, ou alors se fixer sur un noeud du document => on met en forme graphiquement le document.
|
||||
|
||||
En XPath, un document XML est vu comme une arborescence dans laquelle chaque partie du document est représentée par un noeud.
|
||||
|
||||
Il y a 7 types de noeuds :
|
||||
* root : élément maître
|
||||
* element : un élément
|
||||
* attribute : un attribut
|
||||
* text : contenu
|
||||
* comment : commentaire
|
||||
* processing instruction : instruction de tâche??
|
||||
* namespace : espace de nom
|
||||
|
||||
----
|
||||
Vendredi 4 avril 2008
|
||||
|
||||
<code xml>
|
||||
<?IUTprocessus exemple="fig1.xml?>"
|
||||
</code>
|
||||
cible = chaîne associée
|
||||
|
||||
A chaque noeud de l'arborescence XPATH est associée __une chaîne de caractères__ ( String - Value ) et un __nom étendu__.
|
||||
|
||||
Un nom étendu est constitué d'une partie locale et d'une URI (Uniform Resource Identifer) d'espaces de nom.
|
||||
|
||||
===== Recherche dans un document XML =====
|
||||
|
||||
La recherche commence à partir d'un noeud de contexte.\\
|
||||
tout les résultats d'une recherche sont relatifs à ce noeud.
|
||||
|
||||
Un axe indique quel ensemble de noeud, relativement ou noeud de contexte, peut être inclus dans le résultat d'une recherche. Cet axe impose également un ordre sur les noeuds.
|
||||
|
||||
Il y a deux types d'axes :
|
||||
* Les axes en descendant (forward axes) séléctionnent les noeuds qui suivent le noeud de contexte.
|
||||
* Les axes en montant (revers axes) séléctionnent les noeuds qui précèdent le noeud de contexte.
|
||||
|
||||
===== Chemin de localisation =====
|
||||
|
||||
==== Notation ====
|
||||
|
||||
Axe :: test_de_noeud[prédicat]
|
||||
|
||||
==== Exemples ====
|
||||
|
||||
* child :: * : séléctionne tous les éléments fils de type élément du noeud de contexte
|
||||
* child :: text() : séléctionne tous les élement fils de type 'text' du noeud de contexte
|
||||
|
||||
==== Combinaison de deux chemins de localisation ====
|
||||
|
||||
Avec le symbole : '/'
|
||||
|
||||
=== Exemple ===
|
||||
<code xml>
|
||||
child :: * / child :: text()
|
||||
</code>
|
||||
|
||||
Séléctionne tous les petits - fils de type **text** du noeud de contexte.\\
|
||||
La 2ième séléction s'applique sur l'ensemble des noeuds obtenu par la 1ère séléction.
|
||||
|
||||
=== Abréviation ===
|
||||
|
||||
/descendant_of_self :: node() / child :: body
|
||||
|
||||
%%//%% body : séléctionne tout les éléments body d'un document
|
||||
|
||||
<code xml>
|
||||
/livres/livre/traduction[. = "japonais"]/../titre
|
||||
</code>
|
||||
Ce chemin séléctionne les titres de chaque libre ayant une traduction en japonais.
|
||||
|
||||
=== Remarque ===
|
||||
|
||||
[.="japonais"] compare la chaîne associé du noeud courant à la chaîne "japonais".
|
||||
|
||||
==== Fonctions et opérateurs d'ensemble de noeuds ====
|
||||
|
||||
head | body : séléctionne tous les noeuds head et body fils du noeud de contexte
|
||||
|
||||
last() : renvoie le dernier élément de l'ensemble de noeuds.
|
||||
|
||||
=== Exemples ===
|
||||
|
||||
<code xml>
|
||||
head / title[last()]
|
||||
</code>
|
||||
Séléctionne le dernier élément title
|
||||
|
||||
<code xml>
|
||||
livre[position()=3]
|
||||
</code>
|
||||
Séléctionne le 3ième livre, s'écrit aussi livre[3]
|
||||
|
||||
Count(*) renvoie le nombre d'éléments fils du noeud de contexte
|
||||
|
||||
==== Les fonctions de chaînes ====
|
||||
|
||||
Elles permettent de manipuler les chaînes associées aux noeuds de l'arborescence.
|
||||
<code xml>
|
||||
concat(chaîne1,chaîne2,chaîne3)
|
||||
start_with(chaîne1,chaîne2) vrai si chaîne1 commence par la chaîne2.
|
||||
</code>
|
||||
|
||||
====== XSL : Extensible Stylesheet Language Transformations (XSLT) ======
|
||||
|
||||
Un document XSLT est un document XML avec un élément racine "stylesheet".
|
||||
|
||||
XSLT utilise les expressions Xpath pour localiser les noms dans le document XML.
|
||||
|
||||
Dans une transformation XSL il y a deux arbres de noeuds :
|
||||
* L'arbre source (décrit dans le document XML)
|
||||
* L'arbre résultat (document produit par la transformation)
|
||||
|
||||
Pour générer et sauvegarder le fichier résultat de la transformation XSL il faut utiliser la bibliothèque Xerces/Xalan.
|
||||
|
||||
<code java>
|
||||
java org.apache.xalan.xslt.Process -in fichier.xml -xsl fichier.xsl -out nouveaufichier
|
||||
</code>
|
||||
|
||||
===== Les templates =====
|
||||
|
||||
Le template permet de traiter un ensemble d'éléments XML localisés grâce à une expression XPATH :
|
||||
<code xml>
|
||||
<xsl:template match = "expression_xpath">
|
||||
</xsl:template>
|
||||
</code>
|
||||
|
||||
Un template possède toujours un contenu. Ce contenu est placé dans l'arbre résultat chaque fois qu'un élément correspondant à l'expression Xpath spécifiée sera rencontrée dans l'arbre source.
|
||||
|
||||
Appliquer les modèles avec xsl:apply_templates.
|
||||
|
||||
Par défaut, un processus XSLT lit le document XML de haut en bas en commençant à l'élement racine et en descendant dans l'arborescence en suivant l'ordre d'apparition des éléments.
|
||||
|
||||
Cependant il est possible de modifier cet ordre grâce à xsl:apply_templates. C'est l'attribut //select// qui indique les éléments à traiter.
|
||||
|
||||
<code xml>
|
||||
<xsl:template match="nom">
|
||||
<xsl:value_of select="nom_famille" />
|
||||
<xsl:value_of select="prenom" />
|
||||
</xsl:template>
|
||||
</code>
|
||||
|
||||
<code xml>
|
||||
<xsl:template match="personne">
|
||||
<xsl:apply_templates select="nom" />
|
||||
<xsl:template>
|
||||
</code>
|
||||
|
||||
==== Itération et tri ====
|
||||
|
||||
=== Itérations ===
|
||||
|
||||
<code xml>
|
||||
<xsl:for_each select="expression_xpath">
|
||||
</xsl:for_each>
|
||||
</code>
|
||||
Effectue une même opération sur tous les éléments d'un ensemble de noeuds renvoyés par l'expression XPATH.
|
||||
|
||||
=== Tri ===
|
||||
|
||||
<xsl:sort select="expression_path" order="ascending | descending" />
|
||||
|
||||
|
472
A63/XML-Introduction~
Normal file
472
A63/XML-Introduction~
Normal file
@ -0,0 +1,472 @@
|
||||
====== A63 : Peristance des bases de données ======
|
||||
|
||||
===== Définitions de balises =====
|
||||
|
||||
===== SGML =====
|
||||
|
||||
A la fin des années 1960, Charles GOLDFOND, Edward MOSHER et Raymond LORIE (IBM) construisent un système puissant et portable pour interchanger et manopuler des documents légaux -> utilisation d'un langage de balises
|
||||
Le langage informait de la nature abstraite des informations plutôt que leur mise en page.
|
||||
Les informations de mise en page était spécifiée dans un format appelé feuille de style.
|
||||
|
||||
L'équipe d'IBM décida également de mettre en place un système capable de rejeter des documents invalides (documents avec des informations manquantes ou en surplus) La structure de chaque type de documents fût alors strictement définie dans un efichier appelé DTD (Document Type Definition).
|
||||
|
||||
1969: GML (Generaliszed Markup Language)\\
|
||||
1974: SGML (Standard Generalized Markup Language)
|
||||
|
||||
HTML + CSS (Cascading Style Sheet) crée par le W3C (World Wide Web Consortium)
|
||||
|
||||
XML proposé par le W3C combine la puissance et l'extensibilité de son ancêtre SGML et la simplicité imposées par la communauté du Web.
|
||||
|
||||
Principes :\\
|
||||
* permet de créer des langages de balises pour décrire n'importe quel type de document et appartenant à n'importe quel type de domaine d'une manière structurée : hiérarchique
|
||||
* permet de créer de nouvelles balises
|
||||
|
||||
Analyse de document XML :\\
|
||||
* Lire le document
|
||||
* Contrôle de la syntaxe
|
||||
* Indique les erreurs
|
||||
|
||||
Syntaxe : \\
|
||||
* Un seul élément racine
|
||||
* Chaque élément doit avoir une balise de début et de fin
|
||||
* Les balises doivent être correctement imbriquées
|
||||
* La valeur des attributs doivent être entre guillemets
|
||||
* XML fait la différence entre les majuscules et les minuscules
|
||||
|
||||
=> Un docupment syntaxiquement correct et dit bien formé !
|
||||
|
||||
===== Les caractères autorisées =====
|
||||
|
||||
On différencie : \\
|
||||
* les caractères contenus dans les balises (nom d'élément et d'attributs)
|
||||
* les caractères de données (contenues entre deux balises)
|
||||
|
||||
Certains caractères blancs seront significatifs et d'autres pas.\\
|
||||
Ex : <code xml><balise>C'est un caractère de _ _ _ _ _ données</balise></code>
|
||||
|
||||
On n'utilisera pas d'espaces dans les noms d'éléments et d'attributs.
|
||||
|
||||
Références d'entité et entités prédéfinies : \\
|
||||
&xxx;\\
|
||||
& (&)\\
|
||||
<(<)\\
|
||||
> (>)\\
|
||||
' (')\\
|
||||
"(")
|
||||
|
||||
===== Les balises =====
|
||||
|
||||
==== Définition ====
|
||||
|
||||
Un élément défninit une structure, il peut avoir ou ne pas avoir de contenu (élément fils et des caractères de données). Aucun, un à plusieurs attributs peuvent lui être associés.
|
||||
|
||||
==== Définition 2 ====
|
||||
|
||||
Un attribut décrit un élément. Il sera placé à l'intérieur de la balise de départ d'un élément. La valeur d'un attribut est entourée d'apostrophes.
|
||||
<code xml><voiture porte='4' /></code>. Ceci est un élément sans caractères de données.
|
||||
|
||||
La section CDATA n'est pas traitée par l'analyse XML. Elle peut contenir du texte, des caractères reservées et des espaces. elle est souvent utilisée pour contenir du code script :
|
||||
<code xml><![CDATA[ _ _ _ ]]></code>
|
||||
|
||||
===== Les espaces de nom =====
|
||||
|
||||
La notion d'espace de nom permet d'éviter les collisions de nom.
|
||||
|
||||
Ex: <code xml><sujet>Math</sujet>
|
||||
<sujet>electro encephalographie</sujet>
|
||||
</code>
|
||||
|
||||
Ces deux éléments sujet peuvent être différenciés par des espaces de nom.
|
||||
|
||||
<code xml><ecole:sujet>Math</ecole:sujet>
|
||||
<medecine:sujet>electro encephalographie</medecine:sujet></code>
|
||||
|
||||
Chaque préfixe d'espace de nom est associé à un identificateur de ressource uniforme (URI) qui identifie de façon unique un espace de nom.\\
|
||||
Pour être sûr que l'espace de nom est unique, une méthode consiste à utiliser les URL (Universal Resources Locators). Car les noms de domaines sont toujours uniques.
|
||||
|
||||
===== Avantages de XML =====
|
||||
|
||||
Intérêt de XML : pas toujours besoin de faire des requêtes sur le serveur, le client peut s'en occuper.
|
||||
|
||||
|
||||
====== Les DTD (Document Type Definition) ======
|
||||
|
||||
===== Définition =====
|
||||
|
||||
Définit la structure d'un document XML => valide sa conformité.\\
|
||||
Une DTD est définie en utilisant la grammaire EBNF (Extended Backus-Naur Form)\\
|
||||
Un document XML conforme à une DTD est dit __valide__.\\
|
||||
Un analyseur validant (Ex: Validant XML Microsoft) permet de dire si un document XML est valide ou non.
|
||||
|
||||
===== Déclaration de document type =====
|
||||
|
||||
<code xml><!DOCTYPE nomRacine ></code>
|
||||
|
||||
La DTD peut être soit interne soit externe.
|
||||
|
||||
Déclaration interne :
|
||||
<code xml><!DOCTYPE monMessage[
|
||||
<!ELEMENT monMessage(#PCDATA)>
|
||||
]></code>
|
||||
|
||||
<code xml><!DOCTYPE monMessage SYSTEM "maDTD.dtd"
|
||||
[<!ELEMENT monElement (#PCDATA)>
|
||||
]></code>
|
||||
|
||||
Exemple :
|
||||
<code xml><!DOCTYPE html PUBLIC "http://www.w3.org/TR/html4/strict.dtd"></code>
|
||||
|
||||
===== Déclaration d'élements Type =====
|
||||
|
||||
Un élément est un bloc de base d'un document XML.
|
||||
|
||||
<code XML>
|
||||
<!ELEMENT monelement (#PCDATA)>
|
||||
</code>
|
||||
|
||||
PCDATA est la spécification du contenu, et //monelement// est le nom de l'élément.\\
|
||||
PCDATA veut, ici, signifier que l'élément contient des caractères de données.
|
||||
|
||||
La DTD permet de définir l'ordre et la fréquence des éléments fils
|
||||
* Les séquences sont indiquées avec '**,**'
|
||||
<code xml>
|
||||
<!ELEMENT classe (professeur, étudiant)>
|
||||
</code>
|
||||
* Exactement 1 professeur et 1 étudiant dans cet ordre.
|
||||
* Les choix indiqués par '**|**'
|
||||
Exemple : <code xml>
|
||||
<!ELEMENT dessert (glace | pâtisserie )>
|
||||
</code>
|
||||
* Contient soit une glace soit une pâtisserie, mais pas les deux indicateurs d'occurences
|
||||
<code xml>
|
||||
<!ELEMENT album (chanson+)> : Une occurence ou plus
|
||||
<!ELEMENT album (titre, (titre-chanson,durée)+)> : On devra spécifier une fois au MINIMUM titre-chanson.
|
||||
<!ELEMENT bibliothèque (livre*)> : On peut répéter autant de fois livre qu'on veut dans bibliothèque.
|
||||
<!ELEMENT choix (personne?)> : L'élément choix pourra avoir un élément personne ou pas.
|
||||
</code>
|
||||
|
||||
Voici un exemple plus complet :
|
||||
<code xml>
|
||||
<!ELEMENT ferme (fermier+, (chien*|chat?), cochon*, (chèvre|vache)?, (poulet+|canard*))>
|
||||
</code>
|
||||
|
||||
Ceci donnera :
|
||||
|
||||
<code xml>
|
||||
<ferme>
|
||||
<fermier>Jeanne Dupond</fermier>
|
||||
<fermier>Jean Dupond</fermier>
|
||||
<chat>ponpon</chat>
|
||||
<cochon>tire-bouchon</cochon>
|
||||
<poulet>cocotte</poulet>
|
||||
</ferme>
|
||||
</code>
|
||||
|
||||
===== Déclaration d'attributs =====
|
||||
|
||||
S'effectue avec le mot clé //ATTLIST//
|
||||
<code xml>
|
||||
<!ELEMENT x EMPTY>
|
||||
<!ATTLIST x y CDATA #REQUIRED>
|
||||
</code>
|
||||
|
||||
EMPTY est l'élément vide.\\
|
||||
x : nom de l'élément
|
||||
y : nom de l'attribut
|
||||
CDATA : contenu de l'attribut
|
||||
#REQUIRED : utilisation de l'attribut
|
||||
|
||||
Attributs par défaut : #REQUIRED, #IMPLIED, #FIXED.
|
||||
* #REQUIRED : doit être défini
|
||||
* #IMPLIED : Si l'attribut n'apparaît pas dans l'élément XML peut utiliser n'importe quelle valeur.
|
||||
* #FIXED : la valeur de l'attribut est une constante et ne peut pas être autre chose dans le document
|
||||
<code xml>
|
||||
<!ATTLIST adresse code_postal #FIXED "67730">
|
||||
</code>
|
||||
|
||||
===== Types d'attributs =====
|
||||
|
||||
Il y a 3 types différents d'attributs :
|
||||
* les chaînes (CDATA)
|
||||
* les attributs à jeton
|
||||
* les attributs énumérés
|
||||
|
||||
==== Attributs à jeton ====
|
||||
|
||||
* ID : Identifie de manière unique un élément. XML demande apparemment (expérience de la prof) un caractère alphanumérique d'abord ! Exemple : s1
|
||||
* IDREF : pointe sur un élément ayant un attribut ID. Vérifie si il existe dans le document un élément avec un attribut ID dont la valeur correspond à la valeur de l'attribut IDREF.
|
||||
* NMTOKEN (peu usité) : la valeur ne doit être constituée que de lettres, de chiffres, de tirets (-), de soulignés (_), de deux points (:) et de points (.)
|
||||
|
||||
==== Le type énuméré ====
|
||||
|
||||
Déclare une liste de valeurs possibles pour l'attribut. Ces valeurs sont séparées dans la définition par un '**|**'.
|
||||
<code xml>
|
||||
<!ATTLIST personne genre (M|F) "F">
|
||||
</code>
|
||||
|
||||
==== Les sections conditionnelles ====
|
||||
|
||||
Une DTD permet d'inclure ou d'exlure des déclarations en utilisant des sections conditionnelles.
|
||||
<code xml>
|
||||
<![INCLUDE[ _ _ _ _ _]]> : donne la directive d'inclure l'élément
|
||||
<![INGNORE[ _ _ _ _ _]]> : donne la directive d'ignorer l'élément
|
||||
</code>
|
||||
|
||||
===== Traitement des espaces dans les DTD =====
|
||||
|
||||
* les attributs de type CDATA respectent les espaces
|
||||
* les attributs à jeton (ID, IDREF, NMTOKEN) suppriment les espaces
|
||||
* les attributs de type énuméré suppriment les espaces (normalisation)
|
||||
|
||||
====== Les schémas ======
|
||||
|
||||
Les schémas étudiés ici respectent le standard W3C (World Wide Web Consortium).\\
|
||||
* Le but d'un schéma est de spécifier une structure de document XML.
|
||||
* Utilise la même syntaxe que celle utilisée dans un document XML
|
||||
* Possède plus de possibilités de spécifications que les DTD
|
||||
|
||||
Dans les schémas XML le contenu d'un élément est défini par son nom et son type.\\
|
||||
On distingue les types simples et les types complexes.\\
|
||||
Des types simples sont prédéfinis.\\
|
||||
Ex: String, Integer, decimal\\
|
||||
Un type simple ne peut pas contenir d'éléments fils ou d'attributs.
|
||||
|
||||
Un type complexe peut spécifier des éléments fils et des attributs associés.\\
|
||||
Les éléments peuvent être constitués d'éléments préalablement définis en utilisant les concepts d'agrégation et d'héritage.
|
||||
|
||||
* Agrégation : permet de regrouper un ensemble d'élements à l'intérieur d'un nouvel élément
|
||||
* Héritage : permet d'étendre la définition d'un élément préalablement défini
|
||||
|
||||
----
|
||||
Vendredi 28 mars 2008
|
||||
|
||||
===== Éléments simples =====
|
||||
|
||||
Un élément peut être de type simple ou de type complexe. Le type simple ne peut pas définir de sous - éléments et d'attributs.
|
||||
|
||||
Un type simple peut être référencé depuis l'attribut type des éléments xsd:element et xsd.attribute.
|
||||
|
||||
Un élément xsd:element ou un élément xsd.attribute peut avoir un sous - élément xsd:simpleType sans attribut name définissant ainsi un type anonyme pour cet élément ou cet attribut.
|
||||
|
||||
Des nouveaux types peuvent être dérivés à partir de types existants d'une des 3 façons suivantes :
|
||||
* en restreignant l'intervalle du type de base en utilisant l'élément xsd:restriction
|
||||
* en combinant plusieurs types de base avec l'élement xsd:union.
|
||||
* en autorisant différentes valeurs d'un type de base séparé par un espace avec l'élément xsd:list
|
||||
|
||||
==== Facettes ====
|
||||
|
||||
Les éléments minExclusives, minInclusive... pattern sont appelés des facettes. Elles désignent un aspect d'une valeur possible pour un type simple.
|
||||
|
||||
La facette //pattern// peut désigner des restrictions très sophistiquées sur le format des chaînes de caractères. La facette pattern compare la valeur concernée par rapport à une expression régulière.
|
||||
|
||||
<code xml>
|
||||
<xsd:simpleType name="nss">
|
||||
<xsd:restriction base="xsd:string">
|
||||
<xsd:pattern value="\d\d\d_\d\d_\d\d\d\" />
|
||||
</xsd:restriction>
|
||||
</xsd:simpleType>
|
||||
</code>
|
||||
|
||||
===== Éléments complexe =====
|
||||
|
||||
Les types complexes permettent de définir des sous - éléments et des attributs. Ils peuvent avoir un contennu simple (simpleContent) ou un contenu complexe (complexContent).
|
||||
|
||||
Seuls les éléments peuvent avoir des types complexes. Les attributs sont toujours de type simple.
|
||||
|
||||
Les mauvais types sont définis en utilisant les éléments xsd:complexType.
|
||||
|
||||
L'attribut mixed, s'il possède la valeur vraie, signifie que de l'élément peut avoir à la fois des caractères de données et des éléments fils.
|
||||
|
||||
==== Notion de contenu simple ====
|
||||
|
||||
L'élément xsd:simpleContent est utilisé dans les éléments xsd:complexType dont le contenu est un type simple. Cet élément sert particulièrement lorsque la seule raison pour laquelle un élément ait un type complexe est la définition d'attributs.
|
||||
|
||||
==== Contenu complexe ====
|
||||
|
||||
L'élément xsd:complexContent est utilisé dans les éléments xsd:complexType pour dériver de nouveaux types complexes à partir d'un type complexe existant par extension ou par restriction.
|
||||
|
||||
Lors de la dérivation par extension, l'attribut //mixed// doit avoir la même valeur que l'attribut mixed du type de base. Lors de la dérivation par restriction l'attribut mixed peut avoir la valeur false pour interdire un contenu mixte qui pourrait être utilisé dans le type de base.
|
||||
|
||||
=== Notion de contenu complexe ===
|
||||
|
||||
* L'élément xsd:sequence : indique que les éléments représentés par leur sous - éléments doivent apparaître dans le document dans l'ordre où ils ont été listés.
|
||||
* L'élément xsd:choice : précise que tous les éléments ou groupes représentés par un de ses sous - éléments __peut__ apparaître.
|
||||
* L'élément xsd:all indique que chaque élément représenté par un de ses sous - éléments xsd:element doit être présent. Cependant l'ordre n'a pas d'importance.
|
||||
|
||||
Dans la pratique, les plus utilisés sont //sequence// et //choice//.
|
||||
|
||||
===== Concept de base : déclaration d'attributs =====
|
||||
|
||||
xsd:attribute
|
||||
|
||||
L'attribut **use** peut avoir l'une des 3 valeurs suivantes :
|
||||
* optional : l'attribut est optionnel
|
||||
* prohibited : l'attribut ne doit pas apparaître
|
||||
* required : l'attribut doit apparaître
|
||||
|
||||
====== XML Path Language (XPath) ======
|
||||
|
||||
Préalable à la création de feuilles de style.
|
||||
|
||||
Permet de se balader dans un document XML, et pour aller à tel ou tel endroit du document, ou alors se fixer sur un noeud du document => on met en forme graphiquement le document.
|
||||
|
||||
En XPath, un document XML est vu comme une arborescence dans laquelle chaque partie du document est représentée par un noeud.
|
||||
|
||||
Il y a 7 types de noeuds :
|
||||
* root : élément maître
|
||||
* element : un élément
|
||||
* attribute : un attribut
|
||||
* text : contenu
|
||||
* comment : commentaire
|
||||
* processing instruction : instruction de tâche??
|
||||
* namespace : espace de nom
|
||||
|
||||
----
|
||||
Vendredi 4 avril 2008
|
||||
|
||||
<code xml>
|
||||
<?IUTprocessus exemple="fig1.xml?>"
|
||||
</code>
|
||||
cible = chaîne associée
|
||||
|
||||
A chaque noeud de l'arborescence XPATH est associée __une chaîne de caractères__ ( String - Value ) et un __nom étendu__.
|
||||
|
||||
Un nom étendu est constitué d'une partie locale et d'une URI (Uniform Resource Identifer) d'espaces de nom.
|
||||
|
||||
===== Recherche dans un document XML =====
|
||||
|
||||
La recherche commence à partir d'un noeud de contexte.\\
|
||||
tout les résultats d'une recherche sont relatifs à ce noeud.
|
||||
|
||||
Un axe indique quel ensemble de noeud, relativement ou noeud de contexte, peut être inclus dans le résultat d'une recherche. Cet axe impose également un ordre sur les noeuds.
|
||||
|
||||
Il y a deux types d'axes :
|
||||
* Les axes en descendant (forward axes) séléctionnent les noeuds qui suivent le noeud de contexte.
|
||||
* Les axes en montant (revers axes) séléctionnent les noeuds qui précèdent le noeud de contexte.
|
||||
|
||||
===== Chemin de localisation =====
|
||||
|
||||
==== Notation ====
|
||||
|
||||
Axe :: test_de_noeud[prédicat]
|
||||
|
||||
==== Exemples ====
|
||||
|
||||
* child :: * : séléctionne tous les éléments fils de type élément du noeud de contexte
|
||||
* child :: text() : séléctionne tous les élement fils de type 'text' du noeud de contexte
|
||||
|
||||
==== Combinaison de deux chemins de localisation ====
|
||||
|
||||
Avec le symbole : '/'
|
||||
|
||||
=== Exemple ===
|
||||
<code xml>
|
||||
child :: * / child :: text()
|
||||
</code>
|
||||
|
||||
Séléctionne tous les petits - fils de type **text** du noeud de contexte.\\
|
||||
La 2ième séléction s'applique sur l'ensemble des noeuds obtenu par la 1ère séléction.
|
||||
|
||||
=== Abréviation ===
|
||||
|
||||
/descendant_of_self :: node() / child :: body
|
||||
|
||||
/ body : séléctionne tout les éléments body d'un document
|
||||
|
||||
<code xml>
|
||||
/livres/livre/traduction[. = "japonais"]/../titre
|
||||
</code>
|
||||
Ce chemin séléctionne les titres de chaque libre ayant une traduction en japonais.
|
||||
|
||||
=== Remarque ===
|
||||
|
||||
[.="japonais"] compare la chaîne associé du noeud courant à la chaîne "japonais".
|
||||
|
||||
==== Fonctions et opérateurs d'ensemble de noeuds ====
|
||||
|
||||
head | body : séléctionne tous les noeuds head et body fils du noeud de contexte
|
||||
|
||||
last() : renvoie le dernier élément de l'ensemble de noeuds.
|
||||
|
||||
=== Exemples ===
|
||||
|
||||
<code xml>
|
||||
head / title[last()]
|
||||
</code>
|
||||
Séléctionne le dernier élément title
|
||||
|
||||
<code xml>
|
||||
livre[position()=3]
|
||||
</code>
|
||||
Séléctionne le 3ième livre, s'écrit aussi livre[3]
|
||||
|
||||