Bon, allez, je vais avoir l'air (l�g�rement) lourd, mais j'essaie
de d�fendre ma paroisse.
> - Il n'est pas possible d'utiliser les pratiques courantes de la
> programmation objet, comme le polymorphisme
Je ne suis pas trop d'accord sur ce point. Avec certains builders,
il est possible d'utiliser tes propres contr�les d�rivant des contr�les
SWING de base. A ce moment l�, libre � toi de mettre en place une
architecture te permettant de param�trer ces contr�les.
De toute fa�on, comme on en a d�j� discut� lors d'un pr�c�dent thread,
il ne faut pas utiliser les Swing de base directement. A partir de l�,
si ton builder ne te permet pas d'utiliser tes propres contr�les,
vaut mieux le jeter.
Je suis d'accord pour dire que ca n'est pas la panac�e, loin de l�.
Mais, il me semble que la construction d'interfaces graphiques
n�cessite une approche diff�rente du reste de la programmation objet,
l�g�rement plus pragmatique.
Je ne me demande pas pourquoi les constructeurs d'IHM les plus utilis�s
sont des "choses" comme Visual Basic, PowerBuilder, Acc�ss, etc...
Outre le fait qu'il sont plus faciles d'approche, quand tu veux ajouter
un bouton, tu ajoutes un bouton, tu ne fais pas un factory pour appeler
un objet s�rialis� dont le nom est dans un annuaire JNDI que tu appeles
via SOAP.
Ah, c'est s�r, c'est moins modulaire !!!
D�sol�, je m'emporte un peu. Ca doit �tre l'approche du week-end.
N�anmoins, le probl�me d'optimisation est issu de la lenteur g�n�ralis�e
des JFC. Quand ce probl�me sera r�solu (d'une mani�re ou d'une autre),
ON pourra peut �tre �viter de monter des usines � gaz pour faire des
choses simples.
> - Difficile de maintenir les differentes versions, surtout quand
> plusieurs personnes vont editer le meme panneau (par exemple, probleme
> quand tu fais un diff avec CVS)
L�, effectivement, ca peut poser un probl�me si l'�diteur se met � tout
r�am�nager.
>
> L'ideal:
>
> - Utilise le builder pour creer ton interface
> - Une fois que tu es satisfait, recupere le code et rearrange-le a ta
> facon (abstraire les methods dans une classe commune, utiliser
> l'heritage, etc...)
Malheureusement, TU en es peut-�tre satisfait, mais croire que ton interface
ne va jamais bouger me para�t un peu risqu� (un petit champ suppl�mentaire
au milileu ?)
Olivier
>
> --
> C�dric
>
