Publicité

Affichage des résultats du sondage: Quel est votre framework préféré de gestion de Vue?

Votants
303. Vous ne pouvez pas participer à ce sondage.
  • Struts v1

    30 9,90%
  • Struts v2

    44 14,52%
  • JSF (Java Server Faces)

    103 33,99%
  • Spring MVC

    36 11,88%
  • Wicket

    25 8,25%
  • Tapestry

    14 4,62%
  • GWT

    28 9,24%
  • Autres (précisez)

    23 7,59%
+ Répondre à la discussion Actualité déjà publiée
Page 3 sur 5 PremièrePremière 12345 DernièreDernière
Affichage des résultats 41 à 60 sur 89
  1. #41
    Membre émérite Avatar de Jester
    Inscrit en
    septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 813
    Points : 967
    Points
    967

    Par défaut

    Sinon pour ce que ça vaut :
    rouge = java server faces
    jaunes = spring mvc
    bleu = struts 2



    http://www.google.com/trends?q=strut...ate=all&sort=0

  2. #42
    Invité de passage
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations forums :
    Inscription : juillet 2006
    Messages : 3
    Points : 1
    Points
    1

    Par défaut Bonjour,

    Perso, j'aime bien Azuki (www.azuki-framework.org), en même temps c'est moi qui l'ai fait !

  3. #43
    Membre du Club Avatar de cyrille37
    Inscrit en
    juin 2005
    Messages
    147
    Détails du profil
    Informations forums :
    Inscription : juin 2005
    Messages : 147
    Points : 65
    Points
    65

    Par défaut Tapestry est très très bien

    Salut
    Juste pour dire que ce serai bien que vous alliez découvrir Tapestry. C'est vraiment un très très bon framework. Il est très productif. Son gros défaut à mon avis c'est qu'il manque de docs bien faite pour faciliter sa prise en main.
    Mais avec un p'tit effort, il vaut vraimement le coup.
    Ca serait bien qu'il y ai plus de français qui s'y collent ;-)
    Cyrille.

  4. #44
    Membre du Club
    Inscrit en
    mai 2008
    Messages
    54
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 54
    Points : 65
    Points
    65

    Par défaut

    Je confirme, il faut essayer Tapestry 5. Venant du monde J2SE/Oracle, j'ai récemment (début avril 2008) changé de job et je suis aujourd'hui architecte (et pour le moment unique développeur mais ça va vite changer) et je m'occupe de la création d'un site de commande en ligne.

    Le client est un grand laboratoire pharmaceutique (connu de tous) et le site est à destination des pharmaciens et des médecins.

    Mes contraintes :

    --> le design des écrans a été réalisé par une agence de communication (la plus connue), est plutôt léché et fait sans qu'un "techos" ne bride l'enthousiasme des designers.

    --> le temps de dev: même pas 2 mois pour:
    modéliser une bdd qui valorise des commandes avec des conditions commerciales complexes
    comprendre et migrer les données de l'ancien site (sauce struts + ERP vraiment bof)
    developper et tester le site

    --> Les performances: l'ancien site étant ce qu'on appelle communément dans le jargon une "daube" (et pourtant Dieu sait que j'essaie toujours de respecter l'existant mais là... 1min10 pour avoir accès à l'écran de commande de... 70 articles !!!)

    Aujourd'hui, le pari (appelons un chat un chat) va être tenu (le gros fonctionne) et je tiens absolument à remercier Tapestry en version 5.11 (et aussi maven 2 sans qui je n'en serai pas là )

    Pourquoi :
    --> Il me fallait coller au plus près à ce que l'agence avait produit, et grace aux composants (Layout mon ami) et aux balises tml, j'ai pu rester dans qqchose que je connaissais bien, le html (ça a l'air comme les facelets de chez JSF)

    --> Il fallait que j'optimise mon savoir J2SE à destination de la web app, et le fait de ne faire que du POJO m'a été d'un grand secours (en plus, si j'ai bien fait bcp de php y'a qques années, le coding dans la JSP ne me disait guère)

    --> L'intégration de composants AJAX (script.aculo.us) pour :
    la validation de formulaire (Ah... @Validate) + les regexp + les datefields
    (quasiment uniquement ce dont j'avais besoin)

    --> Grace à l'utilisation massive des @annotations et à l'absence d'XML de configuration, j'ai gagné un temps fou.

    --> Les conventions de nommage sont tout le temps expliquées par HLS (le boss du projet) sur son blog, débattues et font souvent l'unanimité. Je les utilise sans avoir eu besoin de les determiner et cela me procure un gros gain de temps et apporte une vraie structuration à mon appli (vive l'archetype Maven).

    --> Il va même être facilement possible de réutiliser le site en marque blanche car l'ajout de JS ou de CSS se fait aussi par @annotations dans le POJO

    A cela on peut ajouter la facilité avec laquelle on peut implementer le patron de conception IOC (via l'annotation @Inject), la gestion des sessions (@ApplicationState), la persistence entre page (@Persist)...

    Les désavantages:
    --> Pas de doc... en français : mais j'ai habité 2 ans en Irlande alors ça va mais je comprends que cela puisse être rebutant
    --> Si j'en lis vos descriptions, il me semble moins AJAX oriented que Wicket (que j'irais voir)

    Les points en suspens:

    --> Les performances me semblent très correctes mais il n'y a que 5 testeurs en parallèle. Wait & See (au pire on mettra des index de partout )
    --> on va avoir un nouveau developpeur: aura t'il des difficultés à se l'approprier ?

    J'espère que vous comprenez pourquoi j'ai voté Tapestry... en version 5.
    Notez que je l'avais choisi après une longue comparaison...

    Si vous avez des questions et que j'ai le temps, je n'hésiterais pas à vous répondre...

    PS: Salut Robert, on a taffé ensemble, je vais aller voir ton framework, ça me changera de ton middleware

  5. #45
    Invité régulier
    Inscrit en
    janvier 2008
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 6
    Points : 7
    Points
    7

    Par défaut

    Hello,

    Je viens (moi aussi) de commencer à utiliser Tapestry 5 dans mon travail.

    Avant de choisir ce framework, nous avons évidement essayé de se renseigner sur un maximum de framework.
    Et la c'est la jungle, bon disons que les plus populaires sont:

    - JSF
    - Struts 1 & 2
    - JBOSS Seam (basé sur JSF)
    - Wicket
    - Tapestry

    Les contraintes été les suivantes:
    - performance
    - facile à integrer dans un (gros) projet existant, qui utilisait un peu Strut 1
    - séparation forte entre le HTML et le code (un intégrateur nous fournit les pages HTML)

    Struts 1 avait été une expérience douloureuse, Struts 2 semble intéressant, mais la migration de Struts 1 à Struts 2 paraissait périlleuse, en plus Struts 2 part un peu dans tous les sens (plusieurs systèmes de templates, plusieurs librairies de tag etc....)

    JSF a un impact trop important sur le code HTML, il aurait fallut remplacer une grande partie du HTML par des tags JSF.
    Les multiples implémentations de la spécification, pas toujours compatibles entre elles ne rassurent pas...

    Seam est un peu un cas à part, c'est beaucoup plus qu'un simple framework MVC.

    Nous avons donc hésité entre Wicket et Tapestry.

    Wicket a l'air vraiment sympa, mais l'aspect complètement statefull aurait peut être posé des problèmes de perf.
    L'impact vraiment faible sur le HTML est clairement un gros plus, par contre je trouve le code JAVA assez bordelique; Il faut gerer la hiérachie des composant, alors que cette hierachie et déjà présente dans le HTML, c'est un peu redondant non ?
    Cet aspect rend le code vraiment verbeux.

    Nous avons donc finalement essayé de passer à Tapestry.

    On se heurte rapidement à un gros problème, la documentation est.... disons.... succinte
    Par contre un fois qu'on commence à comprendre le principe, ça devient un bonheur.

    Pour ce qui est du HTML, il est possible d'avoir la même chose que wicket, avec juste des t:id="toto" sur les élèments, ensuite une petite annotation dans le code java et c'est bon

    Autre point fort, le framework est vraiment penser pour les perf (voir le cycle de vie de pages notamment).

    Les composant son vraiment facile a créer (pas d'héritage comme dans wicket) et à utiliser.

    Je n'ai pas encore tester l'AJAX.

    Pour moi il reste un seul point noir, je n'ai pas trouver comment personnaliser le mapping des URL, qui sont par convention l'image de vos packages.

    Exemple, la class toto.java se trouve dans fr.mondomaine.monprojet.pages.private, on atteint cette page en allant sur /private/toto

    Voila c'était un peu long, j'espere que je vous ai donné envis d'essayer

    Dernière chose, "Tapestry 5, building web application" par Alexander Kolesnikov est pas mal pour commencer.

    Avoir les sources du projet (tapestry-core surtout) permet de comprendre rapidement le fonctionnement.

  6. #46
    Rédacteur
    Avatar de benwit
    Inscrit en
    septembre 2004
    Messages
    1 670
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 1 670
    Points : 3 524
    Points
    3 524

    Par défaut

    Avec ces deux derniers post, vous me donnez envie d'y jeter un oeil

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  7. #47
    Invité de passage
    Inscrit en
    janvier 2006
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 7
    Points : 3
    Points
    3

    Par défaut

    Bonjour,

    j'ai été séduit par l'approche de Jboss Seam, mais malheureusement je n'a pas eu le temp de me pencher plus dessus ( work oblige ), et il est vrai que j'aimerais le mettre en place sur un projet plus "personnel", auriez-vous un retour d'XP dessus ( pro / cons )

    merci

  8. #48
    Membre du Club Avatar de eracius
    Inscrit en
    décembre 2004
    Messages
    133
    Détails du profil
    Informations personnelles :
    Âge : 31

    Informations forums :
    Inscription : décembre 2004
    Messages : 133
    Points : 50
    Points
    50

    Par défaut et DWR alors ?

    Je me permets de rajouter mon avis de débutant autodidacte J2EE.

    Après avoir commencé à regarder Struts et Tapestry, je me suis vite rendu compte que cette philosophie ne me convenait pas pour le développement.

    J'ai préféré opter pour une architecture plus libre à base d'Ajax via DWR (qui s'appelle de la SOA si j'ai bien compris). Pour faire simple, DWR permet de présenter des objets java en javascript de façon transparente, il suffit d'appeler les fonctions souhaitées et traiter le résultat via une fonction callback (de l'Ajax quoi, mais sans s'occuper des HttpRequest).

    Un exemple rapide pour ceux qui ne connaissent pas :

    Java :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    @RemoteProxy(creator = SpringCreator.class, 
    		 creatorParams = @Param(name = "beanName", value = "maClass"))
    class maClass {
     
    	@RemoteMethod
    	public Object maFonction(String param1, HttpServletRequest request){
     
    	}
    }
    @RemoteProxy me permettant d'injecter un bean Spring via la classe SpringCreator (je travaille avec le combo classique Spring/Hibernate en dessous) mais ce n'est qu'une des solutions possibles.
    L'objet HttpServletRequest permet d'avoir les informations de session et est automatiquement passé à chaque fonction.
    On peut aussi se passer des annotations et utiliser le fichier dwr.xml (mais pourquoi faire compliqué ...)

    Après configuration de DWR dans le fichier web.xml (très simple) et ajout d'un lien vers le fichier .js généré par DWR, on peut utiliser directement le bean dans javascript de cette façon :

    Code :
    1
    2
     
         maClass.maFonction(param1, maFonctionCallback);
    Cette méthode demande de développer d'un côté le code métier java (où dans mon cas une couche qui fait le lien entre le code métier et DWR) et de l'autre un traitement javascript pour l'affichage des valeurs (des outils très pratiques sont fournis par DWR pour l'injection HTML). Une bonne organisation et de la rigueur sont donc nécessaires pour garder un code clair et propre (surtout côté javascript où c'est vite le souk). Le passage de paramètres de javascript->java peut aussi poser problème si on a besoin de passer des objets un peu compliquées (j'ai eu le soucis avec des list de list) mais ça se configure via le fichier dwr.xml.

    La grande souplesse d'intégration est vraiment très agréable pour moi, surtout que j'ai besoin de réutiliser les mêmes objets dans plusieurs pages en modifiant juste le traitement callback sur les valeurs de retour. Mon application est sans aucun rechargement de page ce qui est plus agréable à mon sens pour l'utilisateur, qui oublie qu'il se trouve sur un navigateur (très important dans mon cahier des charges)

    Après, je n'ai pas assez poussé mes investigations dans les autres framework pour vraiment pouvoir dire que mon choix est meilleur qu'un autre mais il me convient bien pour l'instant.

    J'espère que ça pourra en éclairer certains sur une solution alternative

    Edit : j'ai oublié de préciser qu'un couplage de DWR avec un framework orienté composant est complètement possible.

  9. #49
    Invité de passage
    Inscrit en
    novembre 2006
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : novembre 2006
    Messages : 6
    Points : 4
    Points
    4

    Par défaut PAAAAS de WebObjects

    Je participe à cette discussion intéressante :
    je ne vais pas vous faire de la pub pour le meilleur selon moi, mais vous mettre en garde contre le pire framework de tous:
    WebObjects d'Apple.
    Totalement deprecated, mac de m... obligatoire, pauvre x-code de m... en guise d'EDI, un binding objet de la base à la mort-moi-le-noeud, j'en passe et des meilleures.
    Un véritable enfer sur terre.
    Il est possible de le faire tourner sur eclipse, grace à des courageux qui l'ont adapté (mais pas chez nous, 300Klignes à migrer). Mais à l'utilisation c'est pas glorieux.
    En fait, j'ai l'impression qu'Apple l'a mis en OpenSource par manque de personnel pour le maintenir, et cerise sur le gateau: incompatible leopard.
    Je souhaite bonne chance aux bleus-bite qui essayeront d'ajouter une image à leur projet en moins de 5h. Ou à ceux qui espèrent faire du sql pour taper leur base.
    En bref les gars, si on vous parle de WO, passer votre chemin, en courant (c'est contagieux et honteux il parait comme maladie).

  10. #50
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 1 093
    Points
    1 093

    Par défaut

    Je suis assez sceptique à l'utilisation de Spring MCV et/ou Tapestry sur un point : faut-il mixer dans un seul framework la partie graphique (MVC) et la couche métier-database (EJB, persistence).

    Les standards de Sun que sont JSF et JPA ont pour avantage de bien séparer le tout et d'être bon et complet pour les tâches qu'ils executent (même si JSF n'a pas forcemment des performances terribles).

    Pour répondre à la question du débat : je n'utilise pas de framework. JSP (persistence écrite à la main) et Javascript (avec quand même Prototype) me suffisent amplement. Je compte néanmoins me mettre à JPA.

  11. #51
    Membre du Club
    Inscrit en
    août 2003
    Messages
    131
    Détails du profil
    Informations forums :
    Inscription : août 2003
    Messages : 131
    Points : 48
    Points
    48

    Par défaut

    y a-t-il un IDE qui permet d'intégrer facilement Tapestry ou Wicket de manière assez intuitive pour la partie IHM ?

  12. #52
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 674
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 674
    Points : 7 851
    Points
    7 851

    Par défaut

    Citation Envoyé par nicorama Voir le message
    Je suis assez sceptique à l'utilisation de Spring MCV et/ou Tapestry sur un point : faut-il mixer dans un seul framework la partie graphique (MVC) et la couche métier-database (EJB, persistence).

    Les standards de Sun que sont JSF et JPA ont pour avantage de bien séparer le tout et d'être bon et complet pour les tâches qu'ils executent (même si JSF n'a pas forcemment des performances terribles).
    Euh ... je crains que tu te trompes sur ce coup là: ni Spring MVC ni Tapestry ne touchent à la couche persistence ou métier: ils ne touchent qu'à la partie présentation et contrôle.

  13. #53
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 674
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 674
    Points : 7 851
    Points
    7 851

    Par défaut

    Citation Envoyé par Mascotte Voir le message
    y a-t-il un IDE qui permet d'intégrer facilement Tapestry ou Wicket de manière assez intuitive pour la partie IHM ?
    Je ne sais pas pour Taperstry, mais pour wicket, comme la partie présentation est du pur HTML (enfin, presque), n'importe quel éditeur HTML ferait l'affaire, or tous les IDEs Java du marché (eclipse, NetBeans, IntelliJ, etc.) offrent un tel éditeur.

    Sinon, y'a aussi WicketBench (plugin eclipse) qui permet de simplifier les opérations fréquentes de Wicket (générer page HTML + Page Java en une seule étape, regrouper l'éditeur Java/HTML, etc.) mais il n'est pas très à jour (parapport à eclipse et à Wicket).

    Pour Netbeans, y'a WicketSupport qui offre des Wizards pour u nprojet Wicket, page Wicket et Panel Wicket.

  14. #54
    Membre du Club
    Inscrit en
    mai 2008
    Messages
    54
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 54
    Points : 65
    Points
    65

    Par défaut

    Citation Envoyé par djo.mos Voir le message
    Je ne sais pas pour Taperstry, mais pour wicket, comme la partie présentation est du pur HTML (enfin, presque), n'importe quel éditeur HTML ferait l'affaire, or tous les IDEs Java du marché (eclipse, NetBeans, IntelliJ, etc.) offrent un tel éditeur.
    même réponse pour Tapestry, c'est "presque" du pur html (du .tml pour tapestry markup language mais y'a une combine pour taffer en html) avec en plus les balises des composants Tapestry standards ou créés.

    Par exemple, si tu as toujours le même block d'adresse dans une commande, tu créés le composant "adresse" en html, et tu l'appelles dans ta page avec la balise <t:adresse/> (t pour Tapestry).

  15. #55
    Invité régulier
    Inscrit en
    janvier 2008
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 6
    Points : 7
    Points
    7

    Par défaut

    Exact, pour l'instant il n'y a pas (à ma connaissance) de plugin pour tapestry 5.

    Mais en affectant la coloration des html aux fichiers .tml t'a deja la coloration syntaxique, la validation du xml (les composant tapestry doivent etre du xml valide), et les tags qui se referment tout seul (testé sous eclipse et netbeans).

    Il manque que la completion en fait .

    @Nicorama: Tapestry ne gère absolument pas la partie métier.
    Pour chaque page web, tu creer un fichier .tml (xml avec le namespace de tapestry sur l'élément racine) et une classe Java (pur POJO, pas d'héritage)
    Ensuite la classe java va te permettre de gerer les elements dynamique de ta page, mais tapestry ne gere absolument pas le métier.

    Tapestry IoC te permet de découpler facilement la présentation du business

  16. #56
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 674
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 674
    Points : 7 851
    Points
    7 851

    Par défaut

    Citation Envoyé par skaalf Voir le message
    Tapestry IoC te permet de découpler facilement la présentation du business
    En fait, c'est l'un des points retenus contre Taperstry: le fait qu'Howard, un excellent programmeur je dois avouer, mais qui réinvente la roue avec son HiveMind ... or dans d'autres frameworks on peut utiliser Spring (JSF, Wicket, Struts, etc.) ou Guice (Wicket, ...).

  17. #57
    Invité régulier
    Inscrit en
    janvier 2008
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 6
    Points : 7
    Points
    7

    Par défaut

    Pas faux .

    Je crois que tu peux quand même utiliser spring.
    (http://tapestry.apache.org/tapestry5/tapestry-spring/)

  18. #58
    Membre du Club
    Inscrit en
    mai 2008
    Messages
    54
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 54
    Points : 65
    Points
    65

    Par défaut

    Citation Envoyé par djo.mos Voir le message
    En fait, c'est l'un des points retenus contre Taperstry: le fait qu'Howard, un excellent programmeur je dois avouer, mais qui réinvente la roue avec son HiveMind ... or dans d'autres frameworks on peut utiliser Spring (JSF, Wicket, Struts, etc.) ou Guice (Wicket, ...).
    Je ne suis pas d'accord, mais ça n'a rien à voir avec Tapestry, je tiens à le préciser pour ne pas me faire taxer de "chauvinisme

    à partir du moment où on peut utiliser ou Spring ou Guice avec Tapestry, le fait de proposer un autre conteneur léger comme Hivemind (quoique c'est un peu différent le Tapestry Ioc), c'est donner "encore plus" le choix à l'utilisateur final. D'où l'existence des Pico, Azuki...

    Sinon, on dit, tout le monde utilise Spring et on n'en parle plus. Je crois que cette concurrence est saine pour Spring lui même.

    D'ailleurs, HLS explique qu'il reprend des idées de Guice mais il explique pourquoi il ne l'utilise pas.


    Cette page explique la raison d'être de Tapestry IoC : http://tapestry.apache.org/tapestry5/tapestry-ioc/

    Selon moi, cette concurrence est saine et positive

  19. #59
    Candidat au titre de Membre du Club
    Inscrit en
    février 2005
    Messages
    37
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 37
    Points : 13
    Points
    13

    Par défaut

    J'ai encore du mal à comprendre le but d'intégrer Spring à Wicket. Qu'est-ce que Wicket ne permet pas de faire (suffisamment bien) sans Spring ?

  20. #60
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 674
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 674
    Points : 7 851
    Points
    7 851

    Par défaut

    Rien justement
    Je veux dire que wicket et Spring ne jouent pas dans la même catégorie : Wicket s'occupe de la partie présentation/contrôle, tandis que Spring est utilisé pour plein d'autres choses dans les autres couches (métier, daos, etc.):
    - Conteneur de beans/injection de dépendances
    - Pour la gestion des transactions
    - Pour appliquer des aspects
    - etc.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •