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. J'adopte donc autant que possible un point de vue pragmatique voire un peu naïf et il est possible que je manque de recul et de critique sur ce qui se fait ailleurs. Mon point de vue sur Struts est construit à partir de ma relative expérience avec, et du reste de mon expérience de programmeur. Je suis très sensible à l'élégance du code, la réutilisabilité, la conception objet, et la compacité. Je trouve que dans ces aspects, Struts est intéressant :
- 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
- la définition des formulaires dans le fichier de configuration permet une définition compacte de ceux-ci
- 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
- les JSP sont de longueur raisonnable et dépourvus de saucissonage html/code
- l'internationalisation est gérée de manière transparente
Vraiment ? Tu trouvers vraiment que le design MVC est soluble dans le web ? Pas moi. Ces trois parties ne sont pas représentables dans une application web. J'en veux pour preuve une question simple : pour toi, où se situent les vues, modèles et contrôleurs dans une application comme LinuxFr ?
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).
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.
Tu trouves ça normal, toi, qu'un framework comme ça ne te dise rien quand un mapping n'est associé à aucune JSP ou à une JSP inexistante.
Je ne sais pas. Tu as sûrement raison pour ce point mais je pense que c'est du domaine du détail.
Et pour finir, est-ce que tu peux raisonnablement dire que ça présente un intérêt de développer des applications web schizophrènes, où la moitié de l'application réside dans des classes Java, et l'autre dans un seul fichier XML (ce qui est de plus très pratique pour le travail en groupe).
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 ? 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.
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. 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.
[^] # Re: Struts or not ?
Posté par gc . En réponse à la dépêche Conception et déploiement J2EE - Critique du livre. Évalué à 7.
- 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
- la définition des formulaires dans le fichier de configuration permet une définition compacte de ceux-ci
- 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
- les JSP sont de longueur raisonnable et dépourvus de saucissonage html/code
- l'internationalisation est gérée de manière transparente
Vraiment ? Tu trouvers vraiment que le design MVC est soluble dans le web ? Pas moi. Ces trois parties ne sont pas représentables dans une application web. J'en veux pour preuve une question simple : pour toi, où se situent les vues, modèles et contrôleurs dans une application comme LinuxFr ?
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).
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.
Tu trouves ça normal, toi, qu'un framework comme ça ne te dise rien quand un mapping n'est associé à aucune JSP ou à une JSP inexistante.
Je ne sais pas. Tu as sûrement raison pour ce point mais je pense que c'est du domaine du détail.
Et pour finir, est-ce que tu peux raisonnablement dire que ça présente un intérêt de développer des applications web schizophrènes, où la moitié de l'application réside dans des classes Java, et l'autre dans un seul fichier XML (ce qui est de plus très pratique pour le travail en groupe).
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 ? 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.
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. 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.