Index: buix/doc/analyze-guide.rst
diff -u /dev/null buix/doc/analyze-guide.rst:1.1
--- /dev/null	Mon Sep  6 15:46:13 2004
+++ buix/doc/analyze-guide.rst	Mon Sep  6 15:46:08 2004
@@ -0,0 +1,119 @@
+La finalité de document est d'expliquer les choix de conception de
+Buix.
+
+Propriétés layout des composants
+================================
+ 
+Utilisation du mécanisme d'introspection:
+
+	- Impossible d'utiliser Introspector de Java (le mécanisme ne
+	réagissait pas comme nous le souhaitions)
+	
+	- Développement d'une classe LayoutIntrospector avec une
+	méthode getLayoutInfo(Class clazz) qui retourne une instance
+	de LayoutInfo
+
+	- Développement de LayoutInfo équivalent à BeanInfo. Chaque
+	layout possède sa classe layoutInfo.
+
+En fait, les layouts ne sont pas des beans. En effet, certaines de
+leurs propriétés ne possèdent pas de méthodes get et set. C'est
+pourquoi, elles ne sont pas reconnues en tant que
+PropertyDescriptor. Je devais donc créer des PropertyDescriptor
+adaptées à ces propriétés spéciales. Ainsi, le LayoutInfo pouvait
+retourner une liste de PropertyChildDescriptor. L'objet
+PropertyChildDescriptor se présente comme PropertyDescriptor. Il
+possède un nom, un type, un éditeur, etc. Cette classe possède aussi
+deux méthodes abstraites : - abstract public Object getValue(Object
+comp); - abstract public void setValue(Object comp, Object newValue);
+
+Chaque classe de propriété spéciale du layout va hériter de cette
+classe PropertyChildDescriptor.
+
+Je n'ai pas expliqué pourquoi il existait une méthode « add(Container
+container, Component component) » dans chaque layoutInfo. La méthode
+add est par défaut celle de Java sauf pour un layout : le
+BorderLayout. En effet, lorsqu'on ajoute des composants dans le
+container, ceux-ci doivent avoir une valeur « place » par
+défaut. Ainsi, le premier aura la valeur « Center », le deuxième «
+North » etc. Il est nécessaire de gérer le cas où il n'y a plus de
+place dans le container. En outre, lorsque toutes les places sont
+prises sauf une et qui en plus n'est pas la dernière par défaut, le
+composant doit s'ajouter par défaut à cette place libre, par exemple
+au centre
+
+
+ClipBoard
+=========
+
+Le clipboard se base selon le même principe que le preview sauf qu'il
+a fallu instancier un nouvel arbre, une nouvelle instance de
+BuixGlassPane et un nouveau modèle, mais surtout un nouveau
+SwingTreeNode. Il a fallu aussi effectuer des copies en profondeur en
+utilisant la sérialisation (méthode makeDeepCopy).
+
+Chargement des composants Swing et des interfaces générées
+==========================================================
+
+Le chargement des onglets s'effectue par le parcours d'un ou plusieurs
+fichiers xml. Il y a trois fichiers XML qui sont parsés.
+
+Le parcours est réalisé à l'aide de l'objet SaxReader implanté dans
+DOM4J. A chaque fois que le tag <widget> est rencontré, on récupère
+l'attribut shelf qui va déterminer la valeur de la bibliothèque dans
+laquelle le composant sera classé. L'attribut « class » permet de
+connaître le composant. Une fois que ces deux valeurs sont connues, il
+est possible d'instancier un WidgetButtons. Dans le cas des
+LayoutButton, le cas est quasi similaire. La différence provient des
+tags du fichiers XML. Il n'existe pas de tags widgets mais des tags
+layout. Par contre, nous pouvons constaté la présence des attributs
+shelf et class.
+
+WidgetsButtons : boutons qui caractérisent les composants
+LayoutButtons :  boutons qui caractérisent les layouts.
+
+Ces fichiers xml se trouvent dans une arborescence particulière :
+src/resources. L'application va alors chercher à cet endroit les
+fichiers xml pour charger les différentes entités présentes dans tous
+les fichiers xml du répertoire. Toutefois, il est indispensable que
+les fichiers xml se terminent soit par -widget.xml pour les entités de
+types widget, soit par -layout.xml.
+
+Ces fichiers xml peuvent également se trouver dans un fichier
+jar. Ainsi, il est possible de charger des entités préalablement
+créées ou générées. En effet, ces fichiers jar sont chargés dans le
+classLoader. Ensuite une méthode parcourt en profondeur le répertoire
+et les fichiers jar ou zip, afin de retourner la liste des fichiers
+xml correspondant au pattern passé en paramètre, dans notre cas
+*. xml.  Cette méthode statique se trouve dans un autre module de Code
+Lutin : LutinUtil. Elle est développée dans la classe Ressource
+
+
+Encoders
+========
+
+Les interfaces créées sont sauvegardées avec XMLEncoder.L'organisation
+des données dans le fichier xml n'était pas vraiment adaptée à
+l'utilisation postérieure du fichier. Des informations étaient
+inutiles et d'autres redondantes. En outre, la présentation était trop
+détaillée, on trouve en particulier les méthodes Java comme
+addLayoutComponent. De plus, il n'y avait aucun sous composant au
+container de type Chorem. C'est pourquoi, un autre encoder a été
+développé.
+
+En premier lieu, nous avons souhaité créer un encodeur qui hériterait
+de XmlEncoder. Le principe est d'utiliser le même système de parcours
+que l'encodeur de Java mais en surchargeant les méthodes writeObject,
+writeStatement, writeExpression afin de récupérer, dans un premier
+temps, seulement les éléments qui nous intéressent. Ces éléments sont
+stockés dans des HashMap. Dans un deuxième temps, les HashMap sont
+lues en partant de l'élément racine pour ensuite construire le fichier
+xml. Voici l'implantation lors de la lecture des données et la
+construction du fichier xml. Nous avons constaté l'ordre dans lequel
+sont mises les données dans l'uimodel.
+
+Cet encoder fonctionnait très bien avec les panels créés dans
+Buix. Par contre, il existait de nombreux problèmes. Ces problèmes
+sont décrits dans la documentation bilanExport.rst.
+
+