Autres (précisez)
Bonjour,
J'ai voté "Autres", car à titre personnel, j'utilise en général plutôt de petits outils qui font le boulot plutôt que de gros frameworks qui s'approchent des usines à gaz.
Le framework que j'utilise pour faire ma couche web est WebMotion (http://www.webmotion-framework.org), qui me sert quasi exclusivement à définir mes routes (comme dans Play!, par exemple).
Voici les raisons de mon choix :
- simplicité d'utilisation (centralisation des chemins applicatifs dans un fichier unique, bien moins verbeux qu'un fichier XML ou qu'un farandole d'annotations)
- cohésion avec mon approche orientée outils, je préfère choisir mes outils spécialisés dans leur domaine, que prendre les mastodonte qui font tout, même le café (ex: Spring et ses modules, Play!).
- surchouche API Servlet, le standard Java EE
- documentation complète et support réactif
Dans le cadre professionnel, je l'utilise également pour tout ce qui est réalisation de PoC (Proof of concept). Tandis que pour d'autres projets, Spring MVC a été imposé.
Bonus : il s'agit d'un projet libre.
J'utilise Play 1 pour le travail et play 2 pour des projets perso. Franchement je ne pourrais pas revenir aux anciens framework genre spring mvc et struts et surtout pas jsf.
Je n'ai jamais connu un framework si productif, léger et en plus chouette à utiliser.
Bonjour,
Tout le monde dit que play est fantastique, à ceci je me pose certaines questions.
J'ai testé rapidement play il y a environ 1 an à l'époque de la 1.x et je me suis dit "C'est ce qu'il me faut". Récemment je l'ai considéré pour une nouvelle application et là j'ai été franchement rebuté par leur version 2.0.
J'ai l'impression qu'ils ont opéré un gros gros virage en direction de Scala, de plus j'ai trouvé la documentation de cette V2 assez brève et peu convaincante, en tout cas elle me laisse de nombreuses questions en suspens. Et surtout pour ma part je m'y retrouve pas dans ce mélange java / scala. En plus ils semblent avoir évolué vers leur propre stack serveur qui n'a rien à voir avec les servlets et ce sans proposer de solution intermédiaires, ce qui est bloquant pour plein de personnes.
Bref, franchement pourquoi ils ont fait cette v2? A voir c'est carrément un nouveau projet qu'ils ont fait, ils avaient qu'à l'appeler play4scala. Ca aurait donné une chance à cette extrêmement prometteuse v1 de ne pas mourir. De toutes façons ça doit être tellement dur de migrer de v1 à v2 que ça pouvait très bien être un autre projet. Perso j'ai du mal à faire confiance à des développeurs qui n'hésitent pas à foutre tout un projet par terre parce qu'ils ont été soudainement séduits par un nouveau langage à la mode.
C'est le coeur du framework qui est maintenant en scala, tu peux toujours faire du java avec. Leur nouveau système de template utilise la syntaxe de scala mais franchement y a pas grand chose à connaitre (if, for, etc...) et puis y a des modules qui te permettent d'utiliser l'ancien système encore (groovy)
Pour le serveur ils ont toujours rejeté les servlets même dans la V1 mais il reste toujours un module qui permet d'exporter l'application en war que ce soit pour la V1 ou la V2 et franchement quand on voit les performances ils ont bien fait de rejeter les servlets
La V1 n'est va surement pas mourir crois moi, surement elle n'aura pas de nouvelles fonctionnalités mais les responsables eux même de play en encore beaucoup de client sous play 1 pour l'abandonner comme ça.
Etant un utilisateur convaincu de la V1 et en voyant les possibilités de la V2, je le dis sans aucun problème qu'ils ont fait un excellent choix pour la V2.
A un moment si on veut avancer il faut casser la compatibilité entre les versions, regarde struts 1 et 2 par exemple.
Ouais comme tu dis, y'a des modules... Seulement j'ai tendance à pas trop me fier à ce qui s'écarte de l'officiel. Par ailleurs je suis pas le seul a avoir eu l'impression que Scala était largement mis en avant par rapport à java.
https://groups.google.com/forum/#!to...WUc/discussion
Alors le support de la compilation en war pour la 2 est surement pas si vieux que ça, au moment ou j'ai regardé c'était dispo que pour la 1.x. Et faut dire que c'est absent de la doc v2. C'est intéressant.Pour le serveur ils ont toujours rejeté les servlets même dans la V1 mais il reste toujours un module qui permet d'exporter l'application en war que ce soit pour la V1 ou la V2 et franchement quand on voit les performances ils ont bien fait de rejeter les servlets
Pour ce qui est de dropper les servlets, il faut savoir que tout le monde n'a pas qu'une seule application dans son serveur et les moyens de tout lâcher pour se familiariser avec une stack tombée de nulle part. Ca aurait surement pu être une option de maintenir les deux possibilités puisqu'un plugin permet de l'avoir.
Ben ça paraît incertain, perso je vois la V1 comme vivante pour le support des clients existants mais sans plus d'ajouts fonctionnels, quant à savoir si j'investirai dans une version qui a 8 clous sur 10 dans son cercueil....La V1 n'est va surement pas mourir crois moi, surement elle n'aura pas de nouvelles fonctionnalités mais les responsables eux même de play en encore beaucoup de client sous play 1 pour l'abandonner comme ça.
Euh ouais, ça se discute, qu'on ait pas la compatibilité c'est une chose qui est acceptable, par contre là ça me donne vraiment l'impression que c'est plus le même projet. Enfin soit, c'est peut être pas un problème pour certains, mais moi ça me plaît pas.Etant un utilisateur convaincu de la V1 et en voyant les possibilités de la V2, je le dis sans aucun problème qu'ils ont fait un excellent choix pour la V2.
A un moment si on veut avancer il faut casser la compatibilité entre les versions, regarde struts 1 et 2 par exemple.
Bonjour,
J'ai voté Spring MVC mais si on avait pu émettre plusieurs choix, j'aurais indiqué en plus Click : http://click.apache.org
La simplicité et la rapidité d'apprentissage de Click m'ont été un jour fort utiles dans le cadre d'un concours de développement en temps limité
Bonjour,
j'utilise Tapestry5 pour la réalisation d'interface web. Je l'utilise dans le cadre de mon boulot et pour quelques réalisations personnelles. Ce framework me parait assez simple et souple d'utilisation. Je l'apprécie pour plusieurs raisons :
- Sa structure par composant, et notamment ses composants de base beanEditForm et datagrid permettant très simplement de réaliser des formulaires et des listes. La possibilité de créé simplement ses propres composant et d'utiliser ceux des autres.
- Son système de navigation entre les pages
- Sa page de rapport d'erreur parfaitement claire et lisible
- La documentation est classique, en anglais, assez fourni, mais peu de livre disponible. Le tutoriel de démarrage est assez bien fait et permet avec un maven-archetype de mettre une interface d'exemple en place en trois lignes
- La communauté me parait assez active, il y a de plus en plus de "third party components", la mailing list est assez réactive.
Pour information, j'ai trouvé ce lien qui compare le temps de réponse de plusieurs framework, dont Tapestry5...
http://www.jtict.com/blog/rails-wick...play-lift-jsp/
JSF2 et Grails qui méritait d’être dans la liste à mon avis
Nous n'avons pas voulu expliciter la version même si entre JSF et JSF 2 il y a de gros changement (même chose entre Struts et Struts 2).JSF2 et Grails qui méritait d’être dans la liste à mon avis
Pour Grails, ce n'est pas faux
Mickael
On ne peut pas comparer ce qui n'est pas comparable. Php et un framework Java sont deux chose différentes. Tout le monde fait un site dans le but d'avoir un maximum d'utilisateurs, ton exemple avec le Hello World n'est donc pas bon. Java EE est fait de manière à fonctionner plus rapidement plus le site est visité, il met beaucoup en cache; c'est pour quoi on a 1Go de Ram contre 1% de CPU
Personnellement, j'utilise JSF : Primefaces couplé avec EJB
Pourquoi placer des options exclusives comme ci l'utilisations de ces frameworks s'excluaient mutuellement?
on peut par exemple très bien utiliser Gwt+JSF ou bien Gwt+Wicket.
J'ai personnellement eu à utiliser ces deux combinaisons
Je suis assez surpris du nombre de dév. qui, comme moi, utilisent JSF !
Je suis sur la version 2 (plus précisément un vaste projet de ré-écriture d'un framework qui utilisait la version 1) et je dois reconnaître que c'est plutôt agréable comme framework.
Performant, bien intégré à Netbeans, je pense assez pérenne, avec une forte communauté (contrairement à Tapestry que j'ai utilisé sur mon précédent projet...)... sauf à Toulouse. Ici, très peu de boites l'utilisent. C'est dommage car il y a des projets de qualité autour.
Enrichi d'un omnifaces par exemple, ça permet de faire du HTML5 avec AJAX. C'est plutôt sympa.
Mais des commentaires que j'ai lu plus haut, j'ai bien envie de découvrir Play! ... après le problème c'est qu'à Toulouse son utilisation reste epsilonnesque !
J'avoue que Tapestry n'est pas désagréable à utiliser. Par contre, si tu as un jour utilisé la v3, tu peux tout réapprendre pour passer à la 4. Et pareil, quand tu maîtrises la v4 et que la v5 arrive... tu repars de zéro. Le responsable du framework part vraiment dans ses idées et la rétro-compatibilité, c'est pas son fort !
Pire, le support d'AJAX. C'est bien fait, ça marche bien et surtout c'est super simple à utiliser... sauf quand tu veux sortir des clous plantés par Howard Lewis Ship. Car là, ça devient très vite galère et le développement de mixins pour atteindre tes objectifs peut parfois s’avérer très ardu contrairement à d'autres framework ou tu es moins aidé... mais aussi moins restreint. Reste à savoir où tu places ton curseur d'exigences.
Bonjour,
Je déterre un poil
Cherchant pour un projet quel serait le framework le plus adapté, je trouve votre discussion.
Les propos de _skip m'ont interpellé car mon projet serait un site web à très fort trafic (soyons optimiste) avec une grosse part de contenu créer par les utilisateurs, donc beaucoup de requête vers la bd..
Java ne serait pas adapté à ce type d'utilisation?
Attention à la montée en charge avec hibernate, si tu ne fais pas tout dans les règles, tu peux avoir de sales surprises
C'est bien un site que tu veux faire? Réfléchis bien avant d'opter pour java car c'est difficile à mettre en oeuvre et c'est pas dit suivant ton projet que ça vaille la peine.
Surtout que là visiblement t'as l'air d'être en territoire inconnu. Si tu nous sors de l'EJB pour un forum comme celui sur lequel tu trouves ou quelques choses d'équivalent, y'a des gens qui diraient que tu prends la mauvaise direction.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager