La difference fondamentale entre MlView et conglomerate reside effectivement dans l'architecture multi vues de MlView. Le multi vues est la possibilité a un moment donné d'editer un document XML en utilisant potentiellement plusieurs types de vues. Example, on est en train d'editer le doc en utilisant une vue orienteé "source" (une vue qui ressemble a celle presentée par un editeur tel screem ou bluefish) et subitement, on veut par example couper un sous arbre, et le coller à un autre entre endroit. Pour une telle operation, il est plus adequat d'utiliser une vue arborescente, ou on voit le doc sous la forme de d'un arbre de noeuds.
Hop, on cree une nouvelle vue d'edition sur le meme document. Dans cette vue, hop, on coupe le noeud (le sous arbre) , hop on le colle ou on veut. Hop, on revient sur notre vue orientée source et toutes les modifications qu'on a fait dans la vue arborescente sont repercutées en temps reel sur la vue source courante.
Une telle orientation multi vues necessite des choix architecturaux forts. Ce n'est pas "juste" une question de GUI.
Aujourd'hui, il est vrai que MlView n'offre qu'une vue qui est parfaitement operationnelle. La vue arborescente. Mais nous comptons serieusement developper d'autres types de vues d'editions. Nous pensons qu'en matiere
d'edition XML, il existe plusieurs cas d'utilisation possible. Pour adresser ces differents cas d'utilisation, il est logique de penser qu'il faut plusieurs types differents de vues d'edition. Mais, il fallait bien commencer par une vue ...
Pour les autres, Il nous faut juste du temps (et bien sur, plus de contributeurs ca peut aider ;) ) .
Une autre difference entre conglemerate et MlView reside dans le model de developpement. Pour MlView, nous avons choisis un model de developpement distribué. Nous utilisons GNU ARCH. Chaque contributeur (developpeur, redacteur de doc, designer du site web) a son archive de source. Il produit des patchs et les soumet au mainteneur. Celui ci les integre dans un arbre de source de reference. Chaque contributeur peut par ailleurs, se synchroniser avec l'arbre de reference. Il n'y a pas de depot central de source dans lequel tout le monde doit commettre les sources. Il n'y a donc pas de discrimination faite entre ceux qui ont le droit d'ecriture dans le "CVS" et les autres. Nous synchronisons bien sur
l'arbre de sources de reference avec le CVS de GNOME (les sources de MlView sont aussi presents dans le CVS de GNOME) afin que les traducteurs puissent travailler.
Pour conclure, je dirai que MlView et conglomerate sont
deux manieres d'aborder la problématique de l'edition XML. Le fait d'avoir deux
projets permet de tirer de tirer tout le monde vers le haut et au final, c'est GNOME qui gagne.
[^] # Re: Et Conglomerate ?
Posté par Dodji Seketeli . En réponse à la dépêche Sortie de MlView 0.7. Évalué à 9.
La difference fondamentale entre MlView et conglomerate reside effectivement dans l'architecture multi vues de MlView. Le multi vues est la possibilité a un moment donné d'editer un document XML en utilisant potentiellement plusieurs types de vues. Example, on est en train d'editer le doc en utilisant une vue orienteé "source" (une vue qui ressemble a celle presentée par un editeur tel screem ou bluefish) et subitement, on veut par example couper un sous arbre, et le coller à un autre entre endroit. Pour une telle operation, il est plus adequat d'utiliser une vue arborescente, ou on voit le doc sous la forme de d'un arbre de noeuds.
Hop, on cree une nouvelle vue d'edition sur le meme document. Dans cette vue, hop, on coupe le noeud (le sous arbre) , hop on le colle ou on veut. Hop, on revient sur notre vue orientée source et toutes les modifications qu'on a fait dans la vue arborescente sont repercutées en temps reel sur la vue source courante.
Une telle orientation multi vues necessite des choix architecturaux forts. Ce n'est pas "juste" une question de GUI.
Aujourd'hui, il est vrai que MlView n'offre qu'une vue qui est parfaitement operationnelle. La vue arborescente. Mais nous comptons serieusement developper d'autres types de vues d'editions. Nous pensons qu'en matiere
d'edition XML, il existe plusieurs cas d'utilisation possible. Pour adresser ces differents cas d'utilisation, il est logique de penser qu'il faut plusieurs types differents de vues d'edition. Mais, il fallait bien commencer par une vue ...
Pour les autres, Il nous faut juste du temps (et bien sur, plus de contributeurs ca peut aider ;) ) .
Une autre difference entre conglemerate et MlView reside dans le model de developpement. Pour MlView, nous avons choisis un model de developpement distribué. Nous utilisons GNU ARCH. Chaque contributeur (developpeur, redacteur de doc, designer du site web) a son archive de source. Il produit des patchs et les soumet au mainteneur. Celui ci les integre dans un arbre de source de reference. Chaque contributeur peut par ailleurs, se synchroniser avec l'arbre de reference. Il n'y a pas de depot central de source dans lequel tout le monde doit commettre les sources. Il n'y a donc pas de discrimination faite entre ceux qui ont le droit d'ecriture dans le "CVS" et les autres. Nous synchronisons bien sur
l'arbre de sources de reference avec le CVS de GNOME (les sources de MlView sont aussi presents dans le CVS de GNOME) afin que les traducteurs puissent travailler.
Pour conclure, je dirai que MlView et conglomerate sont
deux manieres d'aborder la problématique de l'edition XML. Le fait d'avoir deux
projets permet de tirer de tirer tout le monde vers le haut et au final, c'est GNOME qui gagne.