Si l'on peut trouver de nombreux livres pour débutants ou experts sur Java, du bon comme du moins bon sur tous les sujets, la plupart du temps discutant autour de logiciels/API propriétaires, il n'en existait peu ou pas du tout, notamment en français, donnant les moyens de se lancer dans la programmation d'applications web en Java à l'aide d'outils Open Source. Ce livre écrit par Jérôme Molière n'est certainement pas la bible de l'Open Source en Java, mais il sort du lot et vous donnera certainement un large panorama des possibilités et les pistes vous permettant d'aller plus loin.
NdM : (précision de l'éditeur) la 2ème édition est en cours pour une publication tout début janvier.
Titre : 2-Conception et déploiement J2EE
Collection : Les Cahiers du programmeur Java
Auteurs : Jérôme Molière
Éditeur : Eyrolles
ISBN : 2-212-11194-0
Pages : 180
Prix : 25 euros (Prix indicatif)
Rédacteur : Florent Zara
Si l'intitulé de ce cahier du programmeur commence par un 2, ce n'est pas sans raisons, En effet, il fait suite à 1-Premières applications professionnelles en Java dans la même collection, même s'il n'est pas du même auteur. Ce dernier présentait les bases (et plus) pour tout programmeur désireux se lancer dans Java. Ce livre prends ce point pour acquis et se propose d'outiller le développeur et le chez de projet afin de pouvoir travailler en équipe de manière efficace.
Précisions et impressions d'ensemble concernant cet ouvrage :
- Un rappel que je ne considère pas comme inutile vu le nombre de livres traduits, c'est une édition originale francophone. Il a été écrit par le dernier mainteneur en date de la FAQ francophone du forum usenet fr.comp.lang.java, à savoir Jérôme Molière. Certifié Sun et JBoss, ce dernier est relativement connu dans le monde Java francophone. Il participe régulièrement à des conférences, notamment au Club Java et certains d'entre vous ont pu le croiser.
- Ce n'est pas un manuel Java ni un guide d'apprentissage du langage. Il vous faut un bagage minimum dans ce langage afin de pouvoir profiter pleinement de ce livre. Avoir fait ou participé à quelques projets me semble le minimum pour bien comprendre le discours de l'auteur tout au long du livre.
- Ce n'est pas non plus un manuel de programmation J2EE comme le titre pourrait le laisser croire si on le lit trop vite. Il s'agit bien de conception (la phase amont du projet) et de déploiement (une des dernières phases). Vous aurez les bases pour comprendre, mais en aucun cas, vous ne maîtriserez J2EE.
- En fait, le livre est principalement axé sur les outils et les méthodes qui ont cours actuellement dans la programmation en Java. On pourrait souvent le comparer à un recueil de bonnes pratiques qui ont fait leurs preuves pour la plupart. En effet certaines pratiques préconisées par l'auteur sont encore balbutiantes, comme l'approche MDA.
- L'auteur insiste clairement sur le côté essentiel de la qualité et son gain futur. C'est une problématique récurrente et un chapitre lui est même consacré, ce qui est encore trop rare de nos jours.
- Enfin, la quatrième de couverture ne trompe pas, la très grande majorité des outils utilisés sont Open Source. Passons maintenant en revue le détail de chaque partie. Le niveau n'est pas forcément progressif, mais la lecture du livre dans l'ordre des chapitres est fortement recommandée étant donné que la trame est la construction d'une application et que ses éléments sont introduits au fur et à mesure. L'introduction pose le contexte (fictif) : une entreprise (la Toile Bleue), une équipe (aux noms très américains), un projet pilote simple mais compréhensible par le plus grand nombre (un gestionnaire de signets). Les orientations sont tout de suite données : on va mettre en oeuvre les nouvelles technologies, et on devine le rôle important de l'Open Source. C'est ici que je formulerais mon premier et plus gros reproche au livre : les choix, même si on a tendance à les approuver, donnent l'impression d'être trop souvent téléguidés et semblent vraiment imposés toujours avec les mêmes arguments. Peu de place à la contradiction. Mais continuons... Le premier chapitre présente les bases de l'évolution d'une architecture à 2 couches vers une architecture à 5 couches (ou plus). On a un panorama des outils et des frameworks qui vont être utilisés pour chacune des couches et des phases de la construction de notre application. Avec le second chapitre, on rentre dans le vif du sujet, i.e. la description de l'environnement de base du développeur. CVS et Ant. Celui-ci d'ailleurs fera partie du fil conducteur du livre, parfois plus que l'application que l'équipe doit développer. Présenté à juste titre comme le couteau suisse du développement Java, tous les outils présentés (ou presque) se verront intégrés dans un buildfile. Et c'est confirmé, BlueWeb va utiliser de l'Open Source à outrance ;) Le chapitre 3 aborde la première des couches : le client en SWT et la vérification de saisie à l'aide des expressions régulières. Côté outil, vous découvrirez JUnit et Log4J. On continue la descente dans les couches au chapitre 4 avec la présentation des données. Au menu, Servlets et Sérialisation en XML pour le transfert des données entre couches (SOAP est aussi abordé). C'est l'occasion d'aborder le premier Design Pattern : "Commande" via un exemple tiré de JBoss. Le chapitre 5 est entièrement consacré aux objets métiers. Après un bref rappel sur les EJB qui seront utilisés pour leur mise en oeuvre, suivi d'une mise en application simple, l'auteur nous présente la manière de tirer parti des doclets afin de générer automatiquement du code avec XDoclet. Vient ensuite la phase de déploiement au chapitre 6 à l'aide de Java Web Start, et un petit rappel opportun sur la signature des fichiers jar. Cela résout de nombreuses problématiques de déploiement et de mises à jour souvent ignorées et remises à plus tard. De nouveaux Designs Patterns sont aussi au programme : Adapter, Singleton et Factory. Le chapitre 7 est un des plus intéressants : l'audit du code et la qualité logicielle. Cette dernière est trop souvent négligée et vous découvrirez qu'il suffit de peu de choses pour améliorer grandement la maintenance et la qualité du code produit. Cependant, il faut que cet aspect soit intégré au plus tôt. Depuis le respect des conventions de développement jusqu'au respect de l'architecture en passant par les tests unitaires Le chapitre 8 n'est rien d'autre que le rassemblement des pièces du puzzle, notamment la partie métier de l'application et la configuration de JBoss. Mais ne vous attendez pas à trouver l'application finie clefs en main. Au contraire, on vous donne les clefs pour pouvoir la terminer. Les exemples et extraits de listing sont parfois un peu long et pourraient être avantageusement condensés au strict minimum nécessaire pour la compréhension lors de la lecture. Les lecteurs intéressés ont toutes les références pour trouver les exemples complet et les étudier plus avant. Pour terminer, j'aimerais mettre en valeur (i.e. lister) toutes les technologies/outils OpenSource Java (ou non) décrites ou seulement mentionnées dans les marges (mais toujours avec un lien). À de rares exceptions, l'auteur fera toujours le choix de l'OpenSource lorsque la technologie est disponible et éprouvée.
- Ant, équivalent de Make pour Java ;
- JUnit, framework de test unitaire ;
- Log4J, bibliothèque de gestion des traces ;
- Oro, gestion des expressions régulières ;
- CastorXML, sérialisation d'objets en XML ;
- XDoclet, pour la manipulation de doclets ;
- AndroMDA, génération de classes à partir du modèle UML (XMI) ;
- Tomcat, serveur d'application ;
- JBoss, serveur d'application J2EE ;
- Checkstyle et PMD, vérifient le respect des normes de développement ;
- Jalopy permet de vérifier et remettre en forme le code source ;
- ImportScrubber et CleanImport, pour la gestion des directives d'import ;
- JDepend, calcule les métriques de Robert Martin ;
- Macker, capable de vérifier si une architecture définie est respectée ;
- Cruise Control, assure la gestion du processus d'intégration continue ;
- Eclipse et SWT, l'IDE modulaire originaire d'IBM et le framework graphique sur lequel il repose ;
- Lucene, moteur de recherche ;
- Rachel, pour simplifier la gestion des URL ;
- PostgreSQL, SGBD ;
- CVS, Système de gestion de version ;
- OpenLDAP, Implémentation OpenSource du protocole de gestion d'annuaires de réseau.
- J2EE en général et les EJB en particulier pour la gestion des composants métiers coté serveur ;
- Java Web Start, automatise le déploiement d'application.
- Avant-propos - [4 pages] - Fichier PDF (235.2 Ko)
- Table des matières - [2 pages] - Fichier PDF 162.9 Ko)
- Introduction - [8 pages]
- Chapitre 1 : Une Architecture à 5 couches pour BlueWeb [10 pages] - Fichier PDF (381.9 Ko)
- Chapitre 2 : Environnement de développement CVS et Ant - [10 pages] - Fichier PDF (1008.6 Ko)
- Chapitre 3 : Interfaces graphiques pour la couche cliente - [26 pages]
- Chapitre 4 : Couche de présentation des données - servlets HTTP - [24 pages]
- Chapitre 5 : Couche métier avec les EJB - [33 pages]
- Chapitre 6 : Déploiement de l'application et gestion des versions avec ANT et Java Web Start - [12 pages]
- Chapitre 7 : Audit du code et qualité logicielle - [28 pages]
- Chapitre 8 : Implémentation de la logique métier BlueWeb avec XDoclet- [26 pages]
- Index - [3 pages]
- La fiche du livre sur le site Eyrolles
- Codes sources des exemples
- Présentation au Club-Java par l'auteur (Attention, format propriétaire inside)
- Le projet Apache Jakarta
- Site Officiel de Java/J2EE
- Fiche du livre (site de l'éditeur) (39 clics)
Au delà des quelques reproches formulés, ce livre est une très bonne base pour le développeur java ou une équipe qui veut franchir le pas vers J2EE en utilisant des outils Open Source, sans pour autant se retrouver noyé sous des pavés de 500 pages, utilisant des technologie propriétaires et sans savoir par quel bout commencer. Il aura un meilleur aperçu des forces en présence. Derrière les buzzwords à l'attention du décideur pressé se cache un très bon livre pour les amateurs d'Open Source en Java. J'aurais personnellement re-travaillé le titre pour qu'il prenne en compte ce coté Open Source, très présent (et c'est la raison de cette critique sur ce site). Donc pour terminer, une petite note à l'attention de Jérome Molière, pour sa seconde édition qui ne saurait tarder, renommez votre ouvrage "Conception et Déploiement J2EE avec des outils Open Source" ! Table des matières
# Le commentaire du J2EE Leader...
Posté par ceituna (site web personnel) . Évalué à -10.
[...]
Ben oui... Encore une fois, il y aura beaucoup de troll, pour 0 infos...
/o\
[^] # Re: Le commentaire du J2EE Leader...
Posté par Pierre Tramo . Évalué à -3.
Il serait temps d'évoluer un peu quand même !
[^] # Re: Le commentaire du J2EE Leader...
Posté par ceituna (site web personnel) . Évalué à -3.
[^] # Re: Le commentaire du J2EE Leader...
Posté par Ramón Perez (site web personnel) . Évalué à -4.
Absolument ! Je trouve que ethylator a raison !
[^] # Re: Le commentaire du J2EE Leader...
Posté par Pierre Tramo . Évalué à -8.
Les personnes voulant la disparition de tous les pierre tramo, unnissez vous en votant [+] à ce post.
Ce n'est pas simple de se faire entendre ici, cette pseudo pétition fera peut-être refléchir certaines personnes.
[^] # Re: Le commentaire du J2EE Leader...
Posté par Aldoo . Évalué à -3.
Après tout, c'est un peu la mascotte de DLFP.
Forcément que ça ne plait pas, quand on veut supprimer un symbole !
# Animal
Posté par Ramón Perez (site web personnel) . Évalué à -4.
Pour montrer que Java ne rend pas spécialement intelligent ?
[^] # Re: Animal
Posté par chl (site web personnel) . Évalué à 0.
Non, c'est une vache :
http://www.eyrolles.com/Scan/MaxiScan/9782212111941.jpg(...)
[^] # Re: Animal
Posté par Sten Spårvagnhög (site web personnel) . Évalué à -1.
Tu es sûr ? Il faudrait savoir l'intention de l'auteur. Pour moi, cet âne ne ressemble pas plus à une vache que le renard de firefox ne ressemble à un panda.
[^] # Re: Animal
Posté par chl (site web personnel) . Évalué à -6.
Normal ... le renard de firefox, n'est ni un renard, ni un panda.
C'est un panda rouge : http://fr.wikipedia.org/wiki/Panda_rouge(...)
[^] # Re: Animal
Posté par ceituna (site web personnel) . Évalué à -1.
https://linuxfr.org/~Cooker/16020.html(...)
[^] # Re: Animal
Posté par Ramón Perez (site web personnel) . Évalué à -2.
> Pour moi, cet âne ne ressemble pas plus à une vache que le renard de firefox ne ressemble à un panda.
Très juste !
D'ailleurs pour enrichier le débat, je pense que rappeler à nos fidèles lecteurs cette intéressanté discussion en glissant une petit url qui fait gagner des xp est plutôt pertinent :
http://linuxfr.org/~Cooker/16020.html(...)
Et au fait, si le panda représente la Chine communiste par sa présence en Chine communiste, et le renard le capitaliste par sa fourberie de capitaliste, peut-on y voir une similitude entre un âne se battant contre une vache, vache souvent comparée par le peuple à un éléphant par sa lourdeur. Non ?
[^] # Re: Animal
Posté par Pierre Tramonson . Évalué à -5.
# idée
Posté par TImaniac (site web personnel) . Évalué à 10.
Je trouve en effet ce genre de depêche intéressante, mais rare (forcement c'est pas vraiment une "news").
Un système de notation permettrait également d'avoir un rapide aperçu de l'avis sur tel ou tel bouquin.
pertinentez ou inutilisez si vous êtes d'accord ou non :)
[^] # Re: idée
Posté par Maxx . Évalué à 1.
[^] # Re: idée
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: idée
Posté par Gabriel . Évalué à 2.
# Bravo
Posté par Jiel (site web personnel) . Évalué à -3.
[^] # Re: Bravo
Posté par Ramón Perez (site web personnel) . Évalué à -4.
Les commentaires non plus.
# Couverture
Posté par Ramón Perez (site web personnel) . Évalué à 0.
Mais vous ne pensez pas que ce dessin à traits humoristiques risque d'effrayer le décideur ?
Imaginez-vous avec ce livre sur votre bureau, et le chef qui rentre, qui voit la couverture ! Non, franchement, le monde libre se doit de rester sérieux si il veut pourvoir offrir une alternative crédible aux logiciels propriétaires.
D'ailleurs c'est ce que recommande l'Advocacy Howto :
http://www.freenix.fr/unix/linux/HOWTO/mini/Advocacy-1.html(...)
[^] # Re: Couverture
Posté par Cali_Mero . Évalué à 3.
Les décideurs que je connais, en tout cas, se gardent bien de juger si vite et si mal.
Mais pour ton info, ce bouquin n'est pas libre, ne concerne pas le Libre et n'est pas destiné aux décideurs, mais aux techniciens.
Imaginez-vous avec ce livre sur votre bureau, et le chef qui rentre, qui voit la couverture !
J'ai vu pire sur le bureau de mon chef...
# Pour aller plus loin
Posté par Pierre Tramonson . Évalué à 10.
On aurait pu choisir
- Hibernate http://www.hibernate.org/(...) au lieu de EJB
- Subversion http://subversion.tigris.org/(...) au lieu de CVS
et parler de
- Cocoon http://cocoon.apache.org/2.1/(...)
- Maven c'est bien ? http://maven.apache.org/(...)
- JonAS http://jonas.objectweb.org/(...)
- Enhydra http://enhydra.objectweb.org/(...)
- Lomboz http://www.objectlearn.com(...)
- et bien d'autres.
Mais je ne vais pas faire la fine bouche :)
D'ailleurs je n'ai pas lu ce bouquin il est possible qu'on en parle ici où là. S'il présente effectivement de manière claire l'utilité de chacune de ces briques logicielles, je pense que ce bouquin doit être à déposer dans toutes les mains de dev Java avec un minimum d'expérience.
[^] # Re: Pour aller plus loin
Posté par Gabriel . Évalué à 8.
Java Open Source Programming: with XDoclet, JUnit, WebWork, Hibernate.
J2EE Open Source Toolkit : Building an Enterprise Platform with Open Source Tools (Java Open Source Library)
Jakarta Pitfalls : Time-Saving Solutions for Struts, Ant, JUnit, and Cactus (Java Open Source Library) (Java Open Source Library)
Explorer's Guide to Open Source Java Tools.
Java Tools for Extreme Programming: Mastering Open Source Tools Including Ant, JUnit, and Cactus (pas lu mais si je me souviens bien j avais lu une tres bonne critique)
Java Open Source Development
Un autre livre sur les portails aussi oriente autour de Lucene... ca y est je l'ai retrouve c'est :
Professional Portal Development with Open Source Tools: JavaTM Portlet API, Lucene, James, Slide
Plus ceux qui traitent directement d'un projet open source: JUnit, Hibernate (Junit in action Hibernate in action, deux tres bons livres), Struts in Action et le "Struts" de chez O'Reilly (encore meilleur que le premioer cite) j2ee without ejb (excellentissime)...
Tout ceux-la sont de bons livres.
En fait j'ai franchement le sentiment que les livres sont un moyens pour les auteurs de l'open source de se retribuer, de gagner un peu de notoriete et/ou d'argent. Voire les deux livres de Rod Jonhson, ou les livres presents de Matt Raible ou a venir de Stephane Traumat.
Un moyen agreable de completer la doc, aussi, dans un format plus facile a lire que l'ecran.
Enfin c'est un moyen de faire le point a un moment, de dire en tant aue developpeur ou utilisateur d'un projet open source "on en est la" (cf. le livre sur Hibernate arp exemple)
[^] # Re: Pour aller plus loin
Posté par Stéphane Traumat (site web personnel) . Évalué à 7.
C'est en effet une façon de nous rétribuer pour le temps qu'on passe sur les projets libres...
A noter que mon éditeur ( sourcebeat ) verse une partie des revenus à la communauté "dont je suis issus" : Objectweb :)
http://about.me/straumat
[^] # Re: Pour aller plus loin
Posté par Nicolas Delsaux (site web personnel) . Évalué à 1.
[^] # Re: Pour aller plus loin
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Pour aller plus loin
Posté par Gabriel . Évalué à 2.
Qu'est-ce que tu caracteriserait comme esprit francais concernant les bouquins d'informatique?
# Curieux...
Posté par lezardbreton . Évalué à 4.
Si j'ai bien compris, c'est une étape importante vers une implémentation java libre, non ?
[^] # Re: Curieux...
Posté par Pierre Tramo . Évalué à 2.
ouaaahhhh, juste 7 ans de retard...
[^] # Re: Curieux...
Posté par Pierre Tramonson . Évalué à -1.
Mais ce n'est qu'une première étape. Vivement la suite.
[^] # Re: Curieux...
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
# Livre électronique gratuit
Posté par governator . Évalué à 8.
http://www.theserverside.com/books/sourcebeat/JakartaStrutsLive/ind(...)
[^] # Re: Livre électronique gratuit
Posté par gc (site web personnel) . Évalué à 4.
[^] # Re: Livre électronique gratuit
Posté par Nicolas Delsaux (site web personnel) . Évalué à 1.
Et Struts c'est vraiment bien(tm).
Je m'interroge ... Appel au troll ? Simple méconnaissance du produit ?
Bref. Non, Struts n'est pas, mais alors vraiment pas bien. Du concept au codage, c'est une pourriture infernale à utiliser.
[^] # Re: Livre électronique gratuit
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Livre électronique gratuit
Posté par gc (site web personnel) . Évalué à 2.
Je l'utilise au niveau professionnel et au niveau personnel.
Bref. Non, Struts n'est pas, mais alors vraiment pas bien. Du concept au codage, c'est une pourriture infernale à utiliser.
Du concept au codage, Struts est puissant et efficace (mais chiant à mettre en oeuvre). Bref, Struts c'est vraiment bien(tm).
[^] # Struts or not ?
Posté par Nicolas Delsaux (site web personnel) . Évalué à 2.
Moi aussi, je l'utilise professionnellement, mais je préfère ne pas trop en parler.
Du concept au codage, Struts est puissant et efficace (mais chiant à mettre en oeuvre). Bref, Struts c'est vraiment bien(tm).
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 ?
Rien que cette partie de Struts, qui en forme pourtant la base, est une erreur. Et je ne parle pas du reste (le système d'extension donne le frisson, les DispatchAction sont trop complexes et devraient être interdites, les taglibs me filent des boutons face à la JSTL, ...)
Et tout ça, c'est pour le concept. Pour le codage, c'est une autre paire de manches. 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.
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).
[^] # Re: Struts or not ?
Posté par gc (site web personnel) . É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.
[^] # Re: Struts or not ?
Posté par Nicolas Delsaux (site web personnel) . É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.
[^] # Re: Struts or not ?
Posté par Bertrand D . Évalué à 4.
Cependant, en référence à ton précédent commentaire, je pense que MVC s'applique sans problème aux applis Web (et c'est une bonne chose de l'appliquer). Modèle = ensemble des classes définissant ton modèle (ok, c'est une définition récursive, mais c'est aussi une évidence) / Vue = les pages web/JSP / Contrôleur = le lien entre les deux, c'est à dire les classes qui définissent la logique de ton appli, la réponse aux actions de l'utilisateur, etc.
Tu demandes où sont les listeners: le rôle d'un listener est de déclencher un traitement dans le contrôleur en réponse à une action de l'utilisateur. Dans une appli web (pour rester simple) l'action d'un utilisateur peut être l'activation d'un lien ou le clic sur un bouton dans un formulaire. Donc de manière générale, le listener est implémenté par l'adresse URL (et les paramètres passés dans la requête). Dans le cas de Struts, c'est le paramètre action (HTML ou taglib) des forms, les paramètres de la requête, et le fichier de config (qui définit le mapping entre un URL et une classe).
Pour ce qui est du framework Struts, je pense tout simplement que l'implémentation est foireuse.
Par exemple (et je me contente de citer Rod Johnson -- qu'on a mentionné plus haut), l'un des problèmes de Struts est qu'on doit étendre une classe de base (la plupart du temps Action). C'est d'ailleurs une question dans la FAQ est la réponse est du genre: "oui c'est effectivement gênant, mais c'est comme ça et c'est trop compliqué de le changer maintenant". A mon avis, si le framework ne change pas, les développeurs vont changer de framework, voilà tout!
L'autre gros problème est, effectivement, le fichier de config: la séparation des concepts evoquée plus haut par gc est bénéfique en effet. Le hic c'est que les Actions et le fichier de config recouvrent pour une partie la même logique: le contrôleur. Par ailleurs pourquoi avoir un fichier de config? On ne va pas le changer à l'exécution! Avoir les classes et le fichier de config introduit un risque: le développeur doit veiller à garder les deux synchronisés.
Le détail de l'implémentation ou les solutions ne sont pas toujours géniaux. Je me suis retrouvé plusieurs fois dans une situation où je suis resté perplexe face à l'implémentation.
Par exemple, l'action LookupDispatchAction se base sur le libellé internationalisé du bouton et opère un lookup inversé (i.e. utilise la valeur pour retrouver la clé) dans le fichier de ressource afin de déterminer le nom indépedant du language. Quid si deux boutons aux fonctions différentes ont le même libellé? Ok, je ne cherche pas une solution, je dis simplement que le concept dans ce cas est idiot!
Je ne dirai rien au sujet de la taglib, je pense que tout a été dit par d'autres.
[^] # Re: Struts or not ?
Posté par gc (site web personnel) . Évalué à 4.
En quoi c'est un problème (concrètement) ?
[^] # Re: Struts or not ?
Posté par Nicolas Delsaux (site web personnel) . Évalué à 3.
- Java ne supporte pas l'héritage multiple, ce qui rend impossible l'utilisation d'un autre objet de base qu'Action.
- la classe Action ne fournit à l'implémenteur aucun service utile. Il n'y a pas en effet de méthodes de cette classe qui soient utilisées par les implémenteurs d'Actions struts pour se faciliter la vie. C'est dommage, car une classe de base est, dans le modèle théorisé qui est le mien, un ensemble fonctionnel (ou quasi-fonctionnel) que l'implémenteur d'une classe dérivée pourra utiliser facilement.
Or la classe Action ne fournit pas de services, mais un contrat, ce qui est très différent. En tant que contrat exprimé, elle devrait, en théorie, être une interface, ce qui permettrait aux codeurs d'applications web de l'utiliser à leur gré, et donc de définir réellement leur contrôleur.
Et comme la classe Action est réellement le coeur de Struts, son mauvais codage fait, de ce point de vue, de Struts un mauvais framework.
[^] # Re: Struts or not ?
Posté par Nicolas Delsaux (site web personnel) . Évalué à 0.
[^] # Re: Livre électronique gratuit
Posté par Cali_Mero . Évalué à 4.
Voici ton sauveur :
http://www.bugmenot.com/(...)
A noter qu'il existe aussi un plugin bugmenot pour Mozilla / Firefox :
http://extensions.roachfiend.com/index.php#bugmenot(...)
# Bon livre
Posté par David Sporn (site web personnel) . Évalué à 1.
# La même chose pour débutant
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
j'aimerai savoir si quelqu'un par ici connait un bon bouquin en français, sur le même sujet,
accessible pour quelqu'un (moi en l'occurence) qui connait déjà pas mal le langage en lui même mais pas du tout au fait de tout ce qui tourne autour de J2EE.
Merci
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.