Je voudrais d'abord partir du fait que je ne suis pas un "expert" des appli web, il est probable que tu aies plus d'expérience que moi dans le domaine.
On ne sait jamais, tu peux très bien en avoir beaucoup plus. Mais, venant du développement Swing, Struts m'a toujours choqué.
- la séparation entre les actions et les vues permet de cloisonner dans les classes chaque type d'action, et de bien séparer le calcul d'un résultat de sa présentation
Sauf que, lorsqu'on a différentes parties d'un site assez ressemblante (précisément ce sur quoi je travaille en ce moment), c'est loin d'être pratique : je commence par développer une partie. une fois que c'est fait, je vais essayer d'extraire de mon action et de ma JSP les parties factorisables. Dans la classe Java, ça va. En revanche, le support du refactoring dans une JSP ...
De la même manière, je vais devoir ajouter des tiles, des actions, modifier des formulaires, et je vais me bouffer les doigts parce que la seule validation existante est celle de Struts lui-même, ce qui m'impose de lancer Tomcat à chaque modification pour éviter les ennuis.
D'où une perte de temps franchement non négligeable.
- la définition des formulaires dans le fichier de configuration permet une définition compacte de ceux-ci
C'est pour ça que Beehive, basé sur Struts a précisément rempalcé cette définition par l'utilisation exclusive de Javabeans pour les formulaires. Le code repasse donc en Java, et j'en suis bien content.
- la définition des types actions, des formulaires et des forward dans le fichier de configuration permet à la fois d'avoir un endroit centralisé pour le process flow, et une définition compacte et élégante de celui-ci
Personnellement, je trouve le fichier struts-config illisible, et surtout inutile et redondant. Je ne sais pas si c'est toi qui le disais, mais un pis-aller est l'utilisation de XDoclet pour ne plus avoir à s'en soucier, car ce fichier n'apporte que des ennuis.
- les JSP sont de longueur raisonnable et dépourvus de saucissonage html/code
Et Tapestry ? Et Spring ? Eux permettent aussi l'utilisation de présentations très allégées. Et encore. Parce que pour les JSPs, rien ne t'interdit d'y mettre du code Java (je l'ai encore vu tout récement). Et quand bien même on utilise les taglibs, il est tjours délicat d'insérer, par exemple, des javascripts un peu plus complexes que la simple validation, ce qui enlève beaucoup de son intérêt à la taglib. D'ailleurs, personnellement, je n'utilise plus que la JSTL, et encore, je dois utiliser quatre ou cinq tags : c:out, c:forEach, c:if et c'est à peu près tout.
- l'internationalisation est gérée de manière transparente
Si on utilise la taglib qui va bien, et si on souhaite faire un site internationnal.
Je pense que le MVC de Struts impose certaines restrictions pour les applis web mais ça ne m'a jamais gêné outre mesure (je rappelle ma faible expérience des applis web).
Tu as fait des applis desktop, non ? Avec des listeners ? Bon, dans Struts, où sont-ils ? Alors même qu'il s'agit d'une des briques les plus indispensables du MVC, qui relie la vue au contrôleur, on ne les trouve pas (pas même conceptuellement) dans le modèle de Struts. Quant au contrôleur, où est-il ? C'est Struts ? C'est ton action ? C'est surtout loin d'être clair, et encore plus confus lorsque le chaînage d'action est utilisé (ce qui est très souvent le cas). De la même manière, j'ai personnellement beaucoup de mal à trouver la vue.
Bref, du MVC, on ne retrouve que le modèle, que Struts déclare explicitement ne pas gérer. Super !
Je ne peux pas te donner une réponse toute faite pour linuxfr mais je ne situe pas bien où serait le problème pour linuxfr.
Bon, OK, codes LinuxFr avec Struts. Où sont respectivement ton modèle, ta vue, et ton contrôleur ?
Je ne sais pas. Tu as sûrement raison pour ce point mais je pense que c'est du domaine du détail.
Un détail ne doit pas te faire perdre deux jours. Avec le logging pourri de Struts, c'est la norme. C'est d'ailleurs l'avantage de cet outil. Faire perdre du temps et rendre les projets web stratégiques.
Je ne comprends pas cette critique. Dans l'hypothère d'une appli avec seulement des classes, on peut dire aussi que la moitié réside dans une moitié des classes et l'autre moitié dans l'autre moitié. Tu voudrais qu'une appli soit entièrement dans un seul fichier/classe ?
Non, je voudrais juste qu'une application web n'ait pas à utiliser ces maudits fichiers XML qui sont la plaie du développement J2EE. Le struts-config peut très facilement être remplacé par des annotations (avec Java5) ou des classes intelligement codées. J'en veux pour preuve (encore une fois) que Beehive, la couche de présentation développée par BEA et libérée au profit d'Apache n'utilise pas de manière visible un fichier du genre struts-config. Tout le mapping entre action et JSP est défini grâce à des tags javadocs. Il y aurait pu y avoir mieux, mais c'est déja pas mal du tout.
Je ne comprends pas trop ton raisonnement. La séparation et le cloisonnement me semblent une bonne chose. Que la partie qui définit le contrôle soit dans le fichier de configuration, et que l'implémentation soit faite dans les classes, me semble au contraire un bon concept.
Non; Ce qui est un bon concept, c'est d'avoir un pattern MVC, car c'est celui qui est utilisé dans le développement applicatif depuis un bon bout de temps. Le mauvais concept, c'est de se dire que le contrôleur peut être un simple fichier de config. Parce que dans ce cas-là, cette config est difficilement vérifiable avant exécution, ce qui est une perte de temps que tout chef de projet web appréciera.
Pour le travail en groupe, ça ne pose pas de problème. Chaque développeur peut rajouter une action au fichier dans son coin, dans notre cas nous utilisons CVS et nous n'avons jamais eu de conflit à ma connaissance.
Merci à CVS. Si je pouvais, crois bien que je l'utiliserais. Malheureusement, des contraintes d'entreprise font que je dois utiliser PVCS. Super ! Là, pour travailler avec un fichier, il faut le locker ... Et donc seule une personne peut modifier le fichier struts-config. Encore une fois, la productivité est accrue.
D'autre part je ne sais pas si tu sais que tu peux utiliser plusieurs fichiers de configuration, donc si tu as deux parties bien définies dans ton appli tu peux les définir dans deux fichiers de configuration séparés.
Quand tu as la main sur tous les fichiers de ton appli. Imagines un environnement dans lequel l'équipe de développement n'a pas la main sur le fichier web.xml (c'est souvent possible grâce à des contraintes d'ordre politique). Là, tu rigoles moins.
[^] # Re: Struts or not ?
Posté par Nicolas Delsaux . En réponse à la dépêche Conception et déploiement J2EE - Critique du livre. Évalué à 3.
On ne sait jamais, tu peux très bien en avoir beaucoup plus. Mais, venant du développement Swing, Struts m'a toujours choqué.
- la séparation entre les actions et les vues permet de cloisonner dans les classes chaque type d'action, et de bien séparer le calcul d'un résultat de sa présentation
Sauf que, lorsqu'on a différentes parties d'un site assez ressemblante (précisément ce sur quoi je travaille en ce moment), c'est loin d'être pratique : je commence par développer une partie. une fois que c'est fait, je vais essayer d'extraire de mon action et de ma JSP les parties factorisables. Dans la classe Java, ça va. En revanche, le support du refactoring dans une JSP ...
De la même manière, je vais devoir ajouter des tiles, des actions, modifier des formulaires, et je vais me bouffer les doigts parce que la seule validation existante est celle de Struts lui-même, ce qui m'impose de lancer Tomcat à chaque modification pour éviter les ennuis.
D'où une perte de temps franchement non négligeable.
- la définition des formulaires dans le fichier de configuration permet une définition compacte de ceux-ci
C'est pour ça que Beehive, basé sur Struts a précisément rempalcé cette définition par l'utilisation exclusive de Javabeans pour les formulaires. Le code repasse donc en Java, et j'en suis bien content.
- la définition des types actions, des formulaires et des forward dans le fichier de configuration permet à la fois d'avoir un endroit centralisé pour le process flow, et une définition compacte et élégante de celui-ci
Personnellement, je trouve le fichier struts-config illisible, et surtout inutile et redondant. Je ne sais pas si c'est toi qui le disais, mais un pis-aller est l'utilisation de XDoclet pour ne plus avoir à s'en soucier, car ce fichier n'apporte que des ennuis.
- les JSP sont de longueur raisonnable et dépourvus de saucissonage html/code
Et Tapestry ? Et Spring ? Eux permettent aussi l'utilisation de présentations très allégées. Et encore. Parce que pour les JSPs, rien ne t'interdit d'y mettre du code Java (je l'ai encore vu tout récement). Et quand bien même on utilise les taglibs, il est tjours délicat d'insérer, par exemple, des javascripts un peu plus complexes que la simple validation, ce qui enlève beaucoup de son intérêt à la taglib. D'ailleurs, personnellement, je n'utilise plus que la JSTL, et encore, je dois utiliser quatre ou cinq tags : c:out, c:forEach, c:if et c'est à peu près tout.
- l'internationalisation est gérée de manière transparente
Si on utilise la taglib qui va bien, et si on souhaite faire un site internationnal.
Je pense que le MVC de Struts impose certaines restrictions pour les applis web mais ça ne m'a jamais gêné outre mesure (je rappelle ma faible expérience des applis web).
Tu as fait des applis desktop, non ? Avec des listeners ? Bon, dans Struts, où sont-ils ? Alors même qu'il s'agit d'une des briques les plus indispensables du MVC, qui relie la vue au contrôleur, on ne les trouve pas (pas même conceptuellement) dans le modèle de Struts. Quant au contrôleur, où est-il ? C'est Struts ? C'est ton action ? C'est surtout loin d'être clair, et encore plus confus lorsque le chaînage d'action est utilisé (ce qui est très souvent le cas). De la même manière, j'ai personnellement beaucoup de mal à trouver la vue.
Bref, du MVC, on ne retrouve que le modèle, que Struts déclare explicitement ne pas gérer. Super !
Je ne peux pas te donner une réponse toute faite pour linuxfr mais je ne situe pas bien où serait le problème pour linuxfr.
Bon, OK, codes LinuxFr avec Struts. Où sont respectivement ton modèle, ta vue, et ton contrôleur ?
Je ne sais pas. Tu as sûrement raison pour ce point mais je pense que c'est du domaine du détail.
Un détail ne doit pas te faire perdre deux jours. Avec le logging pourri de Struts, c'est la norme. C'est d'ailleurs l'avantage de cet outil. Faire perdre du temps et rendre les projets web stratégiques.
Je ne comprends pas cette critique. Dans l'hypothère d'une appli avec seulement des classes, on peut dire aussi que la moitié réside dans une moitié des classes et l'autre moitié dans l'autre moitié. Tu voudrais qu'une appli soit entièrement dans un seul fichier/classe ?
Non, je voudrais juste qu'une application web n'ait pas à utiliser ces maudits fichiers XML qui sont la plaie du développement J2EE. Le struts-config peut très facilement être remplacé par des annotations (avec Java5) ou des classes intelligement codées. J'en veux pour preuve (encore une fois) que Beehive, la couche de présentation développée par BEA et libérée au profit d'Apache n'utilise pas de manière visible un fichier du genre struts-config. Tout le mapping entre action et JSP est défini grâce à des tags javadocs. Il y aurait pu y avoir mieux, mais c'est déja pas mal du tout.
Je ne comprends pas trop ton raisonnement. La séparation et le cloisonnement me semblent une bonne chose. Que la partie qui définit le contrôle soit dans le fichier de configuration, et que l'implémentation soit faite dans les classes, me semble au contraire un bon concept.
Non; Ce qui est un bon concept, c'est d'avoir un pattern MVC, car c'est celui qui est utilisé dans le développement applicatif depuis un bon bout de temps. Le mauvais concept, c'est de se dire que le contrôleur peut être un simple fichier de config. Parce que dans ce cas-là, cette config est difficilement vérifiable avant exécution, ce qui est une perte de temps que tout chef de projet web appréciera.
Pour le travail en groupe, ça ne pose pas de problème. Chaque développeur peut rajouter une action au fichier dans son coin, dans notre cas nous utilisons CVS et nous n'avons jamais eu de conflit à ma connaissance.
Merci à CVS. Si je pouvais, crois bien que je l'utiliserais. Malheureusement, des contraintes d'entreprise font que je dois utiliser PVCS. Super ! Là, pour travailler avec un fichier, il faut le locker ... Et donc seule une personne peut modifier le fichier struts-config. Encore une fois, la productivité est accrue.
D'autre part je ne sais pas si tu sais que tu peux utiliser plusieurs fichiers de configuration, donc si tu as deux parties bien définies dans ton appli tu peux les définir dans deux fichiers de configuration séparés.
Quand tu as la main sur tous les fichiers de ton appli. Imagines un environnement dans lequel l'équipe de développement n'a pas la main sur le fichier web.xml (c'est souvent possible grâce à des contraintes d'ordre politique). Là, tu rigoles moins.