CSC 4508 - Traduction: corrigé du TP noté 2007-2008

OpenLaszlo est un logiciel "open source" et gratuit, pour développer des "RIA", "Rich Internet Applications". Un fichier source (suffixe .lzx) contient un mélange de XML (pour la partie statique des composants d'interface), et de de JavaScript (pour les aspects dynamiques). Il est compilé : soit pour le FlashPlayer, soit en code DHTML/JavaScript.

Le but est de montrer combien/comment les techniques actuelles du web dépendent des techniques de compilation, et d'en acquérir les rudiments. L'exercice traite bien sûr d'un sous-ensemble, simplifié, de OpenLaszlo:

on se limite aux balises XML, qui définissent la partie statique
on ne considère pas toutes les balises, etc ...

Précisement, il s'agit de vérifier la correction d'un fichier OpenLaszlo.

Consignes pour le rendu

Rendre sur la plate-forme Moodle, une archive tpnote.tgz contenant les fichiers:

lex1.flex
lex2.flex
gram2.bison
lex3a.flex
lex3b.flex
gram3b.bison
lex3c.flex
gram3c.bison
lex4a.flex
gram4a.bison
lex4b.flex (BONUS)
gram4b.bison (BONUS)
lex4c.flex (BONUS)
gram4c.bison (BONUS)
Makefile

1 - flex : analyse lexicale seule, balises simplifiées

Pour la forme générale des balises OpenLaszlo (en ignorant le cas des balises de commentaires) on a deux possibilités :

balises "isolées" de la forme : <MotCleX .... /> Dans cette ecriture :
- MotCle est un nom de balise OpenLaszlo, p.ex. view... etc
- la partie notée "..." peut contenir des attributs valués. Ignorée ici, cette partie sera traitée en 4
paires de balises homologues, balise ouvrante et balise fermante, de la forme : <MotCleX .....> ... </MotCleX>. Par l'appariement MotCleX-MotCleX, elles délimitent des blocs, qui peuvent à leur tour contenir d'autres balises ou blocs. Mais dans cette question 1, on ne traite ni du bon appariement ni de la bonne structure d'un bloc (c'est l'objet de la question 2), seulement des balises.

----------------- Exemple  1.lzx -------------- 
<canvas>
  <include />
  <view>
    <window />
    <view>
      <window>
	<view />
        <button />
      </window>
    </view>
  </view>
</canvas>
-----------------------------------------------

Q1 - Analyseur lex1.flex (2 points)

Mettre au point un analyseur lex1.flex reconnaissant les balises du fichier 1.lzx

------- Résultat après analyse de 1.lzx -------
[open canvas]
[include]
[open view]
[window]
[open view]
[open window]
[view]
[button]
[close window]
[close view]
[close view]
[close canvas]
-----------------------------------------------

Indications

Le traitement des balises ne nécessite ici aucune expression régulière.
En revanche, l'impression des sauts de lignes sera prise en compte.
On demande aussi l'implantation d'une règle balai affichant tout caractère inattendu en entrée.

Corrigé

lex1.flex

2 - flex+bison : balises simplifiées, vérification d'appariement

Q2 - lex2.flex + gram2.bison (4 points)

Mettre au point un analyseur lex2.flex + gram2.bison

qui vérifie le bon appariement des paires de balises,
qui signale en sortie la compréhension de chaque notion reconnue:
- par encadrement "[...]" au niveau lexical,
- et "<...>" au niveau syntaxique

Ainsi avec 1.lzx on devrait obtenir :

	[<canvas>]
	  [<include />]<Include><LonelyTag><Item>
	  [<view>]
	    [<window />]<Window><LonelyTag><Item>
	    [<view>]
	      [<window>]
	        [<view />]<View><LonelyTag><Item>
	        [<button />]<Button><LonelyTag><Item>
	      [</window>]<Window><Block><Item>
	    [</view>]<View><Block><Item>
	  [</view>]<View><Block><Item>
	[</canvas>]<Canvas><Block><Item>

Indications

Noms recommandés pour les catégories lexicales
- pour une balise isolée, la catégorie lexicale aura le même nom, mais en majuscules. Ex. <include /> => INCLUDE
- pour une paire de balises, les catégories lexicales correspondant aux balises ouvrante, fermante porteront des noms homologues, p.ex. pour <canvas ...> : OP_CANVAS, et pour </canvas> : CL_CANVAS
Notions syntaxiques intermédiaires recommandées
- un LonelyTag peut être un INCLUDE ou un BUTTON ou un WINDOW
- un Block est un bloc OP_VIEW/CL_VIEW, un bloc OP_WINDOW/CL_WINDOW ou un bloc OP_CANVAS/CL_CANVAS
- Notez que la balise window peut être soit de type Block soit de type LonelyTag
- un Item peut être un LonelyTag ou un Block
- une liste de Items

Corrigé

3 - Attributs des balises réelles

En réalité (dans les parties de balise notées "..." en Question 1) les balises ouvrantes ou isolées peuvent contenir des triplets : NomAttribut="valeur". Dans la question 4, nous donnons un exemple complet (4.lxz). Dans cette partie nous ne traiterons que les aspects liés aux attributs.

Q3.a) Étape 1 : analyse lexicale (3 points)

Construire l'analyseur lex3a.flex reconnaissant les seuls composants de triplets, provisoirement en dehors de toute balise.

Exemple d'entrée à traiter :

--------------- 3.dat ------------------------------------------
width="100%" height="100%" bgcolor="0xCCCCCC"
href="resources.lzx"  name="main" title="Details" resizable="true"
text="Check" x="50" y="50"
------------------------------------------------------------------

Indications

Pour chaque nom d'attribut imprimer un nom identique, mais en majuscules, p.ex. : width => WIDTH, x => X, resizable => RESIZABLE, ... etc
- dans l'instruction d'impression spécifier ce nom en toutes lettres. Ne pas chercher à programmer une conversion minuscules/ majuscules ! (en effet dans la suite, ces noms seront ceux de catégories lexicales, et ils seront définis comme constantes par directive %token.
- utiliser une règle expression/action par mot-clé, ne pas chercher à traiter ces differents cas par une règle unique (car dans la suite chaque action devra retourner une catégorie lexicale spécifique)
2ème composant : obligatoirement '=', l'imprimer
3ème composant : valeur XX
- obligatoirement écrite entre double-quotes : "XX"
- à l'interieur des double-quotes on peut avoir :
  - un nombre entier : un ou plusieurs chiffres décimaux consécutifs
  - un pourcentage : un nombre entier suivi de '%' (inutile de vérifier que l'entier est sur [0,100])
  - une couleur : exactement 6 chiffres hexadecimaux, précédés de 0x
  - une chaîne : suite de caractère(s) dont un n'est pas un chiffre, voir précisions en [*] ci-dessous
- pour chacun de ces cas l'analyseur lexical imprimera respectivement INT_V, PERCENT_V, COLOR_V, STRING_V

Pour l'exemple 3.dat, l'analyseur devrait produire :

[WIDTH] [=] [PERCENT_V] [HEIGHT] [=] [PERCENT_V] [BGCOLOR] [=] [COLOR_V]
[HREF] [=] [STRING_V] [NAME] [=] [STRING_V] [=] [RESIZABLE] [=] [STRING_V]
[TEXT] [=] [STRING_V] [X] [=] [INT_V] [Y] [=] [INT_V]

[*] Précisions pour le cas des chaînes

il faut admettre une chaîne vide
tout caractère est possible, sauf '"'
se contenter d'exclure '"' et les chiffres décimaux [amélioration facultative : cette solution acceptant des caractères spéciaux, non imprimables, utiliser une liste explicite]

Corrigé

lex3a.flex

Q3.b) Étape 2: lex3b.flex + gram3b.bison (4 points)

Mettre au point un analyseur lex3b.flex + gram3b.bison qui traite une liste d'atributs sous forme de triplets attribut/=/valeur. À chaque reconnaissance de triplet, l'analyseur syntaxique doit afficher: nom = type de la valeur, par exemple X = INT_V.

Indications

Catégories lexicales recommandées
- Pour chaque composante de triplet
  - créer et retourner la catégorie correspondant au nom de l'attribut (WIDTH, HEIGHT, ...)
  - en particulier, pour '=' retourner '='
  - créer et retourner les catégories INT_V, PERCENT_V, COLOR_V, STRING_V
Règles syntaxiques recommandées
- Définir une règle pour chaque type d'attribut: AttrInt, AttrColor, AttrPercent ou AttrString.
- AttrList définit une liste d'attributs
- Attr définit un attribut pouvant être soit AttrInt, AttrColor, AttrPercent ou AttrString
On suppose que certains attributs sont restreints à certains types de valeur:
- X et Y à INT_V,
- WIDTH et HEIGHT à PERCENT_V
- BGCOLOR à COLOR_V
- HREF, NAME, TITLE, RESIZABLE et TEXT à STRING_V

------- Résultat après analyse de 3.dat -------
[width][=][PERCENT_V]<WIDTH = PERCENT_V>[height][=][PERCENT_V]<HEIGHT = PERCENT_V>[bgcolor][=][COLOR_V]<BGCOLOR = COLOR_V>
[href][=][STRING_V]<HREF = STRING_V>[name][=][STRING_V]<NAME = STRING_V>[title][=][STRING_V]<TITLE = STRING_V>[resizable][=][STRING_V]<RESIZABLE = STRING_V>
[text][=][STRING_V]<TEXT = STRING_V>[x][=][INT_V]<X = INT_V>[y][=][INT_V]<Y = INT_V>
-----------------------------------------------

Corrigé

Q3.c) Étape 3: lex3c.flex + gram3c.bison avec passage de valeurs (3 points)

Développer l'analyseur lex3c.flex et gram3c.bison reprenant l'analyseur de la question précédente en remplaçant les types de valeur (INT_V, STRING_V...) par leur valeur.

Indications

Il faut considérer que toutes les valeurs des catégories lexicales INT_V, STRING_V, PERCENT_V et COLOR_V sont de type chaîne de caractères pour pouvoir traiter aussi bien "50" que "resources.lzx"

------- Résultat après analyse de 3.dat -------
[width][=][PERCENT_V]<WIDTH = "100%">[height][=][PERCENT_V]<HEIGHT = "100%">[bgcolor][=][COLOR_V]<BGCOLOR = "0xCCCCCC">
[href][=][STRING_V]<HREF = "resources.lzx">[name][=][STRING_V]<NAME = "main">[title][=][STRING_V]<TITLE = "Details">[resizable][=][STRING_V]<RESIZABLE = "true">
[text][=][STRING_V]<TEXT = "Check">[x][=][INT_V]<X = "50">[y][=][INT_V]<Y = "50">
-----------------------------------------------

Corrigé

Remarque: si vous ne pouvez pas répondre à cette question, vous pouvez quand même faire la question 4.

4 - flex+bison : reconnaissance balises et attributs

Q4.a) Étape 1: analyse lexicale seule (4 points)

En utilisant les analyseurs lex1.flex et lex3a.flex construits aux questions précédentes, construire l'analyseur lex4a.flex reconnaissant en plus des balises les composantes des triplets attribut/=/valeur.

------------- Exemple :  4.lzx ------------------------------------------------ 
<canvas width="100%" height="100%" bgcolor="0xCCCCCC" >
  <include href="resources.lzx" />
  <view name="main" width="100%" height="100%">
    <window name="details" title="Details"
	    width="50%" height="50%" resizable="true" />
    <view>
      <button text="Check" width="50%" height="50%" x="50" y="50" />
    </view>
  </view>
</canvas>
-------------------------------------------------------------------------------

Indications

A la question 1, une balise était spécifiée entièrement (du '<' ouvrant au '>' fermant) car on supposait les attributs absents. Maintenant, on traite des triplets attribut/=/valeur, mais leur nombre n'est pas connu a priori.
Pour chaque balise ouvrante ou isolée:
- reconnaître les débuts de balise "<XXXX"
- et d'autre part les fins de balise, en différenciant ">" ou "/>"
Pour les triplets, reprendre le même traitement qu'à la question 3a. Produire par exemple :[WIDTH] [=] [PERCENT_V]

-------- Résultat après analyse de 4.lzx -------------------------
[<canvas][width][=][PERCENT_V][height][=][PERCENT_V][bgcolor][=][COLOR_V][>]
[<include][href][=][STRING_V][/>]
[<view][name][=][STRING_V][width][=][PERCENT_V][height][=][PERCENT_V][>]
[<window][name][=][STRING_V][title][=][STRING_V]
[width][=][PERCENT_V][height][=][PERCENT_V][resizable][=][STRING_V][/>]
[<view][>]
[<button][text][=][STRING_V][width][=][PERCENT_V][height][=][PERCENT_V][x][=][INT_V][y][=][INT_V][/>]
[</view>]
[</view>]
[</canvas>]
------------------------------------------------------------------

Corrigé

lex4a.flex

Q4.b) Étape 2 : analyse syntaxique limitée (BONUS)

Mettre au point lex4b.flex, gram4b.bison pour articuler les analyseurs lexical + syntaxique avec une analyse syntaxique limitée : simple récupération des catégories lexicales.

Indications

Catégories lexicales recommandées
- Repartir de l'analyseur lex4a.flex
- Retourner une catégorie lexicale pour le début de la balise ouvrante commençant par BEG_OP (BEG_OP_CANVAS, BEG_OP_WINDOW, ... etc)
- Retourner une catégorie lexicale pour le début des balises isolées include et button: BEG_INCLUDE et BEG_BUTTON
- Pour "/>" retourner une nouvelle catégorie END_TAG
- Pour ">" retourner '>' soi-même
- Pour chaque composante de triplet, reprendre les catégories lexicales de la question 3.
Règles syntaxiques recommandées
- Ne pas repartir des règles syntaxiques précédentes.
- À la place on aura une règle pour chaque catégorie lexicale retournée par l'analyseur lexical : p.ex., recevant BEG_OP_CANVAS l'analyseur syntaxique considère que c'est un BegOpCanvas, et fait une impression de vérification.
- On doit aussi spécifier que le texte en entrée est une liste de tels items.

Q4.c) Étape 3 : analyse syntaxique complète (BONUS)

Mettre au point lex4c.flex, gram4c.bison pour vérifier complètement la syntaxe de l'exemple 4.lzx.

Indications

Règles syntaxiques recommandées
- Adapter les règles de gram2.bison en fonction des nouvelles catégories : p.ex. au lieu de OP_CANVAS, il faut une notion syntaxique OpCanvas, à definir comme succession OP_CANVAS AttribList '>'
- Adapter les règles de gram3b.bison prenant en compte les triplets attribut/=/valeur

CSC 4508, TELECOM SudParis, INF, F. MEUNIER, F. SILBER-CHAUSSUMIER

Last modified: Fri Apr 3 11:13:32 CEST 2009