Discussion :

[Buch]

Bonjour à tous,

j'aimerais connaître vos avis sur SwiXML et savoir pour quelle utilisation vous le préconisez. En gros, j'aimerais connaître ses avantages.

Merci à tous

Buch

[Alec6]

SwiXML c'est le top si tu veux rallonger ton processus de développement.
C'est le cas en général lorsqu'on veut faire de l'objet avec du XML.

En effet on ne peut réduire une IHM Swing à du XML, surtout en ce qui concerne les controles.

A la base l'idée était d'avoir un XML de description IHM non lié à un langage en particulier. Ceci n'est pas fait (voir IBM pour cela).

D'autre part SwiXML comporte des erreurs dans la gestion des threads, le parsing du XML pose (récursif si je me rappelle bien) des problèmes de controle du flux du parseur, de nombreux tags doivent etre ajoutés pour combler tous les composants que Swing ne possède pas et qui doivent etre fait à la main.

En somme on se flingue avec ca.

Perso j'ai du réécrire le Parseur (sous la force).

[calogerogigante]

En effet, suis d'accord avec Alec6.. Et je dirais même plus : rien ne vaut une bonne feuille de papier et un crayon, un peu de GridBagLayout, et une fine touche d'ergonomie pour obtenir de solides IHM en java, qui seront utile aux utilisateurs... Et facile à maintenir...

Moi, je pense qu'il vaut mieux passer un peu de temps à approfondir ses compétences pour savoir comment on crée une bonne IHM directement en java... plutôt que de passer par des intermédiaires et perdre du temps, tout en ne sachant même pas si cela va vraiment nous être utile...

[Buch]

Mais si je veux avoir une interface dynamique, sur laquelle je vais pouvoir ajouter/supprimer des éléments, ne serait-ce pas la meilleure solution?
Sinon, comment faire?

[Alec6]

Une interface dynamique ?

Ca l'est toujours non, sauf en client léger.

Avec Swing tu peux toujours faire du dynamique avec des add(component), remove(), revalidate etc...

Vision objet du monde.

[kisitomomotene]

SwiXML et toutes les technologies analogues à savoir:

- Thinlet, SwingMl, WCTRE etc.. pour Swing et les applets
- Flex pour Flash
- XAML pour Winform
- XUL pour gecko ( qui est intégré à Mozilla)
etc.

revolutionnent un peu la technologie de developpement d'interface utilisateur pour plusieurs raisons:
- elles permettent une claire séparation de rôle entre les graphistes et les programmeurs.
- elles permettent un découplage fort entre l'interface utilisateur et la logique applicative ( le pattern MVC est clairement mis en évidence avec ces technologies).
- elles utilisent un langage de balise et non un langage de programmation, ce qui permet une meilleur prise en main par les graphistes déjà habitués au HTML.
- elles sont basès sur XML, ce qui facilite leur intégration dans des environnements divers.

Si vous concevez une application dont les objectifs majeurs sont la maintenance, la reutilisation, l'intégration, la flexibilité, il faudra à priori choisir l'une de ces technologies.

Dans Java, la technologie WCTRE me semble serieuse.

[Alec6]

C'est du vécu ?

[kisitomomotene]

C'est du vécu ?

Je ne comprend pas bien votre question. Vous demandez si j'ai fais l'expérience de ces technologies?
Ici je ne parle pas particulièrement de SwiXML, mais du principe architectural qu'implitique le type de technologie qui est a beaucoup d'avantage par rapport à Swing, comme je l'ai mentionné dans mon post précédent. Peut être SwiXML a des bugs ( je ne l'ai pas particulièrement utilisé), mais il y a au moins une dizaine d'autre technologie analogue dans Java, WCTRE me semble à priori plus fiable ( c'est un avis perso qui peut être faux)

[Alec6]

La question n'est pas agressive, bien sur;

Je connais bien l'argumentation dont vous faites mention et qui effectivement fait réver. Le fameux découplage MVC et un langage (niveau méta) pour générer les IHM.

Malheureusement ce n'est pas si simple, car en posant un couche supplémentaire on se créé des contraintes, diverses et variées. Tant au niveau de la customization de l'IHM, un peu comme en java script ou lorsqu'un composant n'existe pas on est bien ennuyé, qu'au niveau du controle et de l'architecture, car on est envoyé bien souvent dans une sorte de pattern commande. Le cycle de vie devient également plus difficile à controler.
Ce mode de développement n'est pas sans rappeler le développement Web, et ses contraintes.

Il y a effectivement de l'interet dans les arguments en faveur d'un métalangage IHM, mais le manque de maturité et les restrictions sont un vrai problème. C'est un couche d'abstraction comme l'est un langage avancé sur de l'assembleur. Et il faut parfois revenir à l'assembleur pour des cas particuliers.

Bonne journée