La version 1.0 finale du framework Play est un framework Java « pile complète » qui propose tous les composants nécessaires pour créer des applications Web modernes. Notre souci principal est la productivité des développeurs, avec un cycle de développement « corriger et rafraîchir la page », des messages d'erreurs parfaits affichant le code source de l'application directement dans le navigateur et un « lanceur de tests » intégré qui rend le « développement piloté par tests » naturel.
Play utilise de nombreux composants libres, dont Apache Mina pour la pile réseau, Groovy comme langage de script pour le moteur de template et Hibernate pour le mapping objet-relationnel. Ce framework est basé sur une architecture "Share Nothing" qui aide à construire des applications Web RestFul. Il est possible de déployer l'application sur plusieurs serveurs simultanément (sans besoin de synchronisation), et donc de supporter de très fortes charges. La branche 1.0 est maintenant en mode maintenance, et nous avons commencé à travailler sur la branche 1.1, notamment pour ajouter le support du langage Scala.
Play a une documentation complète et de nombreuses applications de démonstration. Pour bien commencer, nous avons conçu une capture vidéo d'écran d'introduction, le fameux exemple "Hello World" et un guide complet. Enfin, ne manquez pas la session "Play! framework in practice" aux Devoxx 2009.
Aller plus loin
- Play! framework (13 clics)
- Screencast (3 clics)
- Hello World (7 clics)
- Play guide (5 clics)
- Applications d'exemple (3 clics)
- BoF @ Devoxx 2009 (1 clic)
# Mon expérience
Posté par Sphax . Évalué à 4.
Le moteur de template est simple à prendre en main, mais surtout le fait qu'un simple rechargement de la page suffit à prendre en compte les modifs dans le code, c'est le pied.
Pour comparaison, au boulot on était obligé d'utiliser Eclipse avec un plugin Tomcat pour le rechargement automatique, c'est assez lourd.
Surtout aussi, il n'y a pas de fichier de config XML, et ça c'est bien.
Bonne continuation aux développeurs.
[^] # Re: Mon expérience
Posté par kowalsky . Évalué à 2.
Pour comparaison, au boulot on était obligé d'utiliser Eclipse avec un plugin Tomcat pour le rechargement automatique, c'est assez lourd.
C'est un pauvre paramètre dans le server.xml, ou l'on ne parle pas de la même chose !
[^] # Re: Mon expérience
Posté par Sphax . Évalué à 2.
Peut-être que c'est par défaut en fait, je sais plus :/
[^] # Re: Mon expérience
Posté par ★★★ ★★ . Évalué à 3.
Bien sûr avec le plugin eclipse on peut dans certains cas Hotswapper le code Java à chaud mais cela reste le plus souvent impossible. Reste donc à recharger complètement le WAR ce qui peut être long, fait souvent perdre la session, etc...
Play connaît exactement la structure de l'application et recharge intelligemment. Il fait plus que redémarrer simplement l'application. Il informe Hibernate si le modèle à changé, met à jour la base de donnée, re-schedule les Jobs si nécessaire, re-exécute les blocs d'initialisation static si besoin, prend en compte les nouvelles annotations, gère le cache, etc...
[^] # Re: Mon expérience
Posté par syj . Évalué à 0.
Il faut vraiment que le changement de code soit très important pour que je sois obligé de redémarrer le Tomcat lancé par Eclipse. Genre, tu viens de modifier de manière profonde tes objets métiers.
En fait, le problème vient à mon avis du Framework que tu utilises.
Pour que çà fonctionne bien, il faut que tu puisses serialiser à tout moment tous les objets de sessions et que ton système repose assez peu sur des Singleton ou que ceci soit bien indiquer comme Transient car ils ont de forte chance d'être oublié du processus de serialisation.
[^] # Re: Mon expérience
Posté par ★★★ ★★ . Évalué à 2.
Il ne marche ni mieux ni moins bien que ce qui est prévu dans Java. Tant que tu change le corps d'une méthode c'est ok. Dés que tu changes la signature d'une classe (ajout d'une méthode, d'un paramètre, d'un champ) le Hotswap est impossible. C'est comme ca. Et bien sur si il t'es impossible de Hotswapper une classe tout doit être rechargé.
[^] # Re: Mon expérience
Posté par syj . Évalué à 1.
çà se limite à un redémarrage de Tomcat et très souvent je récupère ma session, si elle ne stockait pas la classe impacté par le changement.
Vu que j'utilise un framework "Statefull" (au sens propre), je me retrouve dans l'"écran applicatif" dans lequel j'étais. Ce qui est très pratique quand on développe une partie qui se trouvent plusieurs écran après la connexion à la session.
Le seul truc qui m'embête de temps en temps et que certaines API supportent mal rechargement et les déchargements. Ils maintiennent lock sur des répertoires sans raison ce qui empêche de décharger le WAR et cela m'oblige à arrêter le serveur , finir la désinstallation manuel du war et de relancer le serveur. Ce qui est problématique pour un serveur en exploitation.
Play apporte quoi de plus dans le cas de cette limitation de Java ?
[^] # Re: Mon expérience
Posté par ★★★ ★★ . Évalué à 2.
[^] # Re: Mon expérience
Posté par syj . Évalué à 1.
Pour essayer le tutoriel, de ce que j'ai vu dans la video de présentation (qui est très bien faite).
çà ne me plait pas car j'ai l'habitude d'utiliser un Framework maison qui décrit l'application sous forme d'état et d'action. où toute la structure applicative reste dans des classes Java. çà permet de bénéficier pleinement des fonctionnalités de refactoring et de navigation d'éclipse.
Pour les même raison, j'aime pas les moteurs de Template pour les pages dynamique. Si on veut bénéficier pleinement d'éclipse. Je trouve que les JSP/les tags et une pointe de Java suffise amplement pour gérer la vue. C'est au développeur de se limiter à n'afficher que le modèle qui est présenté par le contrôleur et à ne pas chercher à faire tout et n'importe quoi n'importe où.
[^] # Re: Mon expérience
Posté par ★★★ ★★ . Évalué à 1.
[^] # Re: Mon expérience
Posté par syj . Évalué à 2.
Certes, tu peux stocker l'état du processus métier dans la base de donnée mais quand celui-ci n'a un sens que d'un point de vue applicatif. C'est un peu se compliquer.
Il y a plusieurs moyen de contourné le bouton Back. çà va de supprimer la barre utilisateur ou de contrôler que tu n'exécutes pas deux fois la même action (utilisation d'un cookie qui évolue à chaque action de l'utilisateur, d'un paramètre de formulaire).
Si tu ne fais que du Ajax, la bouton Back n'a plus aucun sens vu que tu n'as jamais changé de page web.
Enfin, même sur une application stateless, le bouton back est problématique. Comment gères-tu si la dernière opération modifié le modèle. Tu l'exécutes une deuxième fois ?
Enfin, les applications Stateless sont plus sensible cross-site-scripting.
Enfin très souvent, les promoteurs du Stateless parle de performance.
Le Statefull consomme juste un peu plus de memoire par session utilisateur.
Imaginons une application de E-commerce qui va géré un panier en Statefull.
L'application gère l'état applicatif de l'utilisateur. C'est à dire son panier, sa position dans l'application. A vue de nez, çà ne devrait pas prendre plus de 10 Ko et encore pour un bon client :).
10 Ko par session sur une machine de 16 Go , çà permet d'en supporter 1 600 000 clients :). C'est pas mal.
Personnellement, mes applications sont interne, j'en aurai jamais autant d'utilisateur.
Après, on peut se demander. Si il est plus rapide d'accéder à la mémoire pour afficher le contenu d'un panier ou d'obtenir un DataSource, lancer une requête SQL.
[^] # Re: Mon expérience
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Sinon, dans nos projets, nous utilisons entre autre Grails et des projets Web java classiques avec Spring lorsque l'IHM doit être réalisé avec des techno comme Flex ou GWT.
J'apprécie bcp Grails pour la rapidité qu'il nous offre dans le dév d'applis et ceci grâce à l'intégration des différentes briques logicielles utilisées comme Spring, Hibernate, etc. mais aussi grâce en grande partie au langage Groovy lui-même.
Toutefois, j'ai vue le screencast de Play! et ce que j'ai vue me plait bcp. Dommage que l'on doit se taper du Java (j'aurais préféré du Groovy quant à faire) mais apparemment Play! rajoute plein de petites choses qui permet de faciliter l'utilisation des objets métier en Java. Dommage qu'il n'y ait pas (encore ?) d'intégration avec maven (la tendance est à ce que les projets dans l'entreprise soient gérés et mis à dispo via maven). En tout cas à suivre.
[^] # Re: Mon expérience
Posté par ★★★ ★★ . Évalué à 4.
C'est bon j'ai compris.
Non sincérement je ne vais pas me lancer ici sur une étude appronfondie des architectures REST. Mais essaye simplement de ne pas tomber dans le piège du réac d'entreprise; "c'est nier l'existence de processus métier qui sont forcement basé sur une succession d'état". Bien sûr que REST permet de gérer les applications avec état. C'est juste qu'il est géré différement.
Et vraiment je te jure. Le jour ou tu arrives reellement à supporter 1 600 000 clients connectés à ton Tomcat (ou ton Websphere si il faut), je m'incline.
[^] # Re: Mon expérience
Posté par syj . Évalué à 1.
C'est le débat qui fait avancer les idées et c'est ce que j'essayais de faire en développant mon argumentaire.
> Le jour ou tu arrives réellement à supporter 1 600 000 clients connectés à ton Tomcat
Je sais. D'expérience, j'ai fait tournée 350 client sur un Websphere qui réalisait une action toutes les secondes (création d'un rendez-vous, création d'une consultation, sauvegarde d'un compte rendu) sur une application statefull, j'en étais très loin :).
[^] # Re: Mon expérience
Posté par nomorepost . Évalué à 2.
En placant toutes les données de session dans un cookie ?
Niveau sécurité on a vu mieux.
[^] # Re: Mon expérience
Posté par syj . Évalué à 1.
Tu pourrais même concevoir un système où serialiser l'ensemble de tes objets de "session" (persistent entre requete) dans la base SQL et ton système les dé-sérialise à la demande ensuite.
çà peut paraitre tordu et lent en performance mais dans le cadre d'un cluster. Chaque requête devient alors indépendante du serveur d'application qui la traite. Il faut alors par contre s'assurer que la grappe de serveur n'exécute qu'une opération à la fois sur la session utilisateur.
[^] # Re: Mon expérience
Posté par nomorepost . Évalué à 3.
Il est indiqué plus haut que tu peux faire du transactionnel avec REST alors que REST impose de n'avoir aucune donnée de session coté serveur.
L'unique solution est donc de stocker sur le client et de concevoir tes requêtes/urls en tenant compte de l'état et des données sur le client
Du coup la simplicité REST part avec le transactionnel et autant revenir au traditionnel id de session et données de session sur le serveur, non ?
Ca n'empêche pas d'appliquer les principes REST pour le non transactionnel.
Enfin c'est ce que je croyais avoir compris.
[^] # Re: Mon expérience
Posté par Jean B . Évalué à 2.
C'est très simple il suffit de suivre la RFC de HTTP. Seules les méthodes POST modifient des données et elles sont suivies d'un redirect.
[^] # Re: Mon expérience
Posté par Moonz . Évalué à 3.
Une requête GET ou HEAD n’est pas censé modifier ton modèle. Pour les requêtes POST et PUT, l’UA est censé demander à l’utilisateur (ce que tous font, à ma connaissance). De plus, tu peux tout simplement répondre un code 3xx sur ta requête POST, et plus de problème.
> Enfin, les applications Stateless sont plus sensible cross-site-scripting.
Évidemment, vu qu’il est tout simplement impossible de faire un lien sur une ressource stateful…
En tant qu’utilisateur, c’est chiant. cf voyages-sncf, par exemple.
# Intelligent
Posté par lezardbreton . Évalué à 5.
[^] # Re: Intelligent
Posté par ★★★ ★★ . Évalué à 8.
Il y a donc une société derrière et nos clients qui utilisent play ont évidemment un support privilégié.
Mais la version est totalement opensource et nous utilisons launchpad, lui même très ouvert aux contributions externes, pour le développement.
# Scala ?
Posté par nomorepost . Évalué à 4.
Ca fait longtemps que ca existe les langages multiparadigmes: fonctionnel+objet+impératif
CLOS, ScmObj (Scheme), Ruby, ocaml, ...
[^] # Re: Scala ?
Posté par blobmaster . Évalué à 4.
je cite :
Scala is fully interoperable with Java.
Sur tout le site, Scala est entièrement définit par rapport à Java.
Je fais du Java et je peux te dire que dans les gens que je côtoient, il y en a plein qui pense que seul Java est le seul langage sérieux (que c'est triste, mais que c'est triste).
Faire faire du Scheme au dev Java de base me parait un doux rêve. Les offres d'emploi Java (J2EE en plus pour moi) sont très centré sur les technos du monde Java. Si tu montres trop de connaissances sur des technos hors ce monde, tu passeras pour un farfelu ou, au mieux, comme ne convenant pas.
J'imagine bien que les dev Scala ont tout simplement voulu apporter au monde Java des choses d'ailleurs. Après J'imagine aussi que des dev Java (genre ceux de Play) iront plus facilement vers Scala que vers Ruby pour la seule raison que c'est dans leur monde. Entre un truc qui se compare tout le temps au Java et qui semble s'y intégrer et un machin qui semble suivre une autre voie, le dev Java choisit le truc, et puis c'est tout.
sinon (désolé pour le lien en Anglais) :
[http://tiago.org/ps/2008/02/24/groovyscalarubypython-on-jvm/]
il y a plein de langages qui tournent sur la JVM.
note: Je sais pas comment dire "monde java" autrement. ça parait flou comme idée. culture, univers, sphère...
[^] # Re: Scala ?
Posté par ★★★ ★★ . Évalué à 3.
Cela va permettre de supporter à la fois Java et Scala pour ceux qui le souhaite sans rien changer dans le framework.
Meme si Scala/Groovy/Python/Ruby peuvent tourner sur une JVM Scala est le seul qui soit complètement compatible avec Java. Une classe écrite en Java ou en Scala est pratiquement la même une fois compilée.
[^] # Re: Scala ?
Posté par JoeBlack . Évalué à 3.
Certes, mais ce n'est pas la seule raison : c'est aussi et surtout que tu n'as pas besoin de porter tout le code que tu as écrit pendant x années en Ruby ou en Python par exemple. Avec Scala, tu peux réutiliser l'existant java : moins de boulot, pour migrer en douceur ; utiliser les fonctionnalités les plus sympas du langage (souvent méconnues des développeurs java il est vrai...), sans avoir à tout reconstruire.
[^] # Re: Scala ?
Posté par nomorepost . Évalué à 4.
Je crois que ca y'est, j'ai la liste des critères:
C'est le seul qui
- tourne sur une JVM
- s'appuie sur l'API de java de base et uniquement dessus
- soit fonctionnel/objet
- soit typé statiquement
Personnellement, je préfère le typage dynamique mais je comprend le besoin.
[^] # Re: Scala ?
Posté par Antoine . Évalué à 2.
Ok, mais alors pourquoi vouloir travailler pour de tels blaireaux ?
[^] # Re: Scala ?
Posté par blobmaster . Évalué à 4.
Je bosse dans une SSII.
Le client est roi, il n'est pas un blaireau, il a raison car c'est lui qui est le client.
Je me permet (plus que beaucoup) de faire des remarques au client sur les bienfaits/méfaits techniques de tel ou tel choix.
Que les techies soient "force de proposition", n'enlève pas son choix au client.
Mon travail n'est pas de faire de la belle ouvrage. Mon travail c'est répondre aux demandes du client et faire ce qui est le mieux pour lui; ces deux points sont souvent contradictoire.
Je travaille avec des gens sympathique et compétent en informatique (les tech de mon équipe). Pour ces raisons et pour d'autres, j'aime mon travail (c'est essentiel), sinon je le ferai pas.
Être compétent en informatique ne signifie pas être compétent en recherche d'emploi. Je ne suis pas à l'aise en entretient alors je vais là ou il y a le plus de boulot. C'est dommage mais c'est comme ça.
L'informatique ça fait peur Du coup le DRH qui veut embaucher et qui capte rien aux choix technique en fait plein.
Derrière Java il y a Sun et IBM et ça rassure. Le DRH qui demande un "developpeur Java", une équipe Java il lit des livres Java, a des chefs de projet Java... Il est entouré il est rassuré il a une perspective : Java !
Du coup quand tu arrives dans un projet Java, tu fais du Java, tu proposes du Java...
En plus, Java, ça fait pas le café, mais bien utilisé, ça permet de t'éclater et mal utilisé, ça fait pas trop de dégat. Du coup tu prends moins de risque en décidant Java car il y a plus de gens à en faire donc moins de recherche, plus de niveaux techniques donc plus de niveaux de salaire... C'est le choix de la facilité pour moi et pour la gestion d'équipe.
Pour beaucoup de développeurs, par ailleurs très doué (fonctionnellement, humainement...), changer de langage n'est pas évident.
Pour toutes ces raisons, certains inducstriels ont besoin d'un petit nombre (idéalement 1) de langages de référence et Java en fait partie, merci Sun.
Une fois fait ce choix, on se retrouve dans la situations décrite plus haut. Ça fait un peu syndrome NIH certe mais ça se comprend je pense.
[^] # Re: Scala ?
Posté par Antoine . Évalué à 4.
Heu, il peut être les deux à la fois.
Je ne suis pas à l'aise en entretient alors je vais là ou il y a le plus de boulot.
C'est un cliché. Une entreprise qui cherche réellement des gens talentueux se fiche qu'ils soient à l'aise en entretien. Les entreprises où ça compte, au contraire, sont les plus chiantes et les plus médiocres.
L'informatique ça fait peur Du coup le DRH qui veut embaucher et qui capte rien aux choix technique en fait plein.
Derrière Java il y a Sun et IBM et ça rassure. Le DRH qui demande un "developpeur Java", une équipe Java il lit des livres Java, a des chefs de projet Java... Il est entouré il est rassuré il a une perspective : Java !
Oui, ben une entreprise où c'est le/la DRH qui prend les décisions de recrutement, y compris pour des métiers techniques, est à fuire immédiatement. Sauf si tu penses que tu ne vaux pas mieux, auquel cas il y a un problème psychologique à régler.
En plus, Java, ça fait pas le café, mais bien utilisé, ça permet de t'éclater et mal utilisé, ça fait pas trop de dégat.
Hum hum.
Pour beaucoup de développeurs, par ailleurs très doué (fonctionnellement, humainement...), changer de langage n'est pas évident.
N'importe quoi. Changer de langage, pour un développeur très doué, ne pose pas de problème (*). D'ailleurs, la plupart du temps ils en maîtrisent plusieurs. Un type qui ne connaît que Java, je ne crois pas qu'on puisse dire que c'est un "développeur très doué", désolé.
(*) sauf si on parle d'Intercal bien sûr
[^] # Re: Scala ?
Posté par blobmaster . Évalué à 3.
Un type qui est capable de changer de langage facilement mais qui comprend rien aux besoins des utilisateurs et est toujours en retard est à mon avis moins doué qu'un type bloqué sur un langage mais capable d'analyser un besoin, de gérer son temps, d'évaluer sa charge...
On ne peut pas être doué partout.
Il faut de tout pour faire un monde.
...
Tu a l'air de mélanger la capacité à développer et la capacité à faire son travail. Dans la vraie vie d'un développeur, le développement n'est pas tout. Il faut aussi interagir avec les autres équipes dont certaines pas techniques. Il faut aussi acquérir (au moins en notions) des compétences sur d'autres domaines (économiques, commerciaux, de gestions..). Cela nécessite d'autres qualités que celles nécessaires en programmation et c'est normal qu'un recruteur s'attarde sur ces qualités aussi.
Quand au fait de demander à un technicien ce qu'il en pense, comment fait tu pour créer l'équipe, s'il n'y a pas de technicien ?
Tu demandes à une société externe ? Oui mais laquelle ? Une qui fait plutôt du Java, une qui fait plutôt du SAP ? Toutes les boites sont un peu spécialisées techniquement.
[^] # Re: Scala ?
Posté par Antoine . Évalué à 4.
C'est qui, "tu"?
Parce que si c'est un commercial ou un DRH nul en technique qui recrute et supervise les équipes techiques, pas étonnant que ça donne n'importe quoi. Dans une entreprise correctement gérée, une équipe de techniciens ou d'ingénieurs sera créée / recrutée par quelqu'un du métier. Et les entreprises d'informatique sont en général créées par des informaticiens, pas par des DRH.
Dans la vraie vie d'un développeur, le développement n'est pas tout. Il faut aussi interagir avec les autres équipes dont certaines pas techniques.
C'est vrai. Mais un développeur est quand même censé maîtriser son métier, et n'être pas capable d'assimiler un deuxième langage est un très mauvais signe.
D'ailleurs, rien que le fait qu'il n'ait pas déjà assimilé un deuxième langage est en soi inquiétant, parce que ça veut dire qu'il ne voit son métier que par le petit bout de la lorgnette (la lorgnette Java, en l'occurence).
[^] # Re: Scala ?
Posté par blobmaster . Évalué à 2.
Il y a des boites qui développent leur logiciels et qui ne sont pas des boites d'informatique. C'est fou non ?
[^] # Re: Scala ?
Posté par Antoine . Évalué à 2.
Donc, encore une fois, si je te cite : « Être compétent en informatique ne signifie pas être compétent en recherche d'emploi. Je ne suis pas à l'aise en entretient alors je vais là ou il y a le plus de boulot. » Ce n'est pas justifié.
[^] # Re: Scala ?
Posté par JoeBlack . Évalué à 1.
Du coup, on peut exploiter toutes les fonctionnalités et tous les avantages apportés par le langage (syntaxe plus claire, closures, redéfinition d'opérateurs, traits, pour ne citer que ceux là parmi tant d'autres), tout en réutilisant l'existant.
[^] # Re: Scala ?
Posté par nomorepost . Évalué à 2.
Mais alors quid de Groovy, Clojure, ...
ou encore des tous ceux là
http://www.is-research.de/info/vmlanguages/functional-progra(...)
Ca serait pas le syndrome NIH ?
[^] # Re: Scala ?
Posté par JoeBlack . Évalué à 1.
En ce qui concerne Groovy, le gros avantage de Scala sur ce dernier est la qualité du bytecode généré. C'est un très bon langage de template cela dit, il est d'ailleurs utilisé dans Play pour les vues.
Bon, après, c'est surtout une question de goûts et de couleurs : typage statique ou dynamique, fort ou faible, etc.
[^] # Re: Scala ?
Posté par nomorepost . Évalué à 2.
En ce qui concerne Groovy, le gros avantage de Scala sur ce dernier est la qualité du bytecode généré.
C'est un point qui peut s'améliorer.
Mais d'après ce que tu dis avec Play il faut donc maitriser Groovy quand même en plus de Java et apprendre Scala.
Pourquoi ne pas tout baser sur Groovy.
D'où mon autre question :
Qu'apporte Play par rapport à Grails ?
[^] # Re: Scala ?
Posté par JoeBlack . Évalué à 2.
Prendre en main Groovy se fait très rapidement, c'est d'ailleurs l'une de ses plus grandes forces.
Tu n'es pas obligé d'apprendre Scala, ni pour la 1.0 ni pour la future 1.1 : le support de Scala est assuré sous forme de module. C'est au développeur, selon sa préférence, d'utiliser Scala ou non.
Pourquoi ne pas tout baser sur Groovy.
[troll]Parce que c'est lent.[/troll]
Plus sérieusement, c'est un parti pris technologique. Remarque, si tu veux utiliser Groovy partout, tu peux effectivement utiliser Grails :)
Qu'apporte Play par rapport à Grails ?
http://www.playframework.org/documentation/1.0/faq#aHowplayc(...)
En résumé : Play est conçu de manière radicalement différente (par exemple, il ne s'appuie pas sur l'API Servlet et donc ne nécessite pas un conteneur comme Jetty ou Tomcat).
[^] # Re: Scala ?
Posté par nomorepost . Évalué à 2.
Tu n'es pas obligé d'apprendre Scala, ni pour la 1.0 ni pour la future 1.1 : le support de Scala est assuré sous forme de module. C'est au développeur, selon sa préférence, d'utiliser Scala ou non.
En fait ma question n'est pas celle là.
Peux t'on se passer de Groovy pour les templates et pourra t'on dans le futur faire du full Scala ?
Sinon merci pour le lien.
Mais là pour le coup c'est vraiment le grand écart.
A part Hibernate et la JVM on garde vraiment rien de ce qui est couramment utilisé en entreprise.
Pas d'API Servlet, en plus je vois que vous utilisez python plutôt que Maven. C'est un vrai risque technologique, si on ne peut pas faire de l'intégration avec d'autres composants.
Est-ce que c'est une approche à la Pylons où on peut prendre des briques que étalage ?
Ici on a quand même pour un dev Java à connaitre:
Python pour le build, Groovy pour le templating un nouvelle API à la place des servlets, un nouveau framework MVC...
Je mesure l'intérêt pour quelqu'un qui souhaite se mettre au WebDev et progresser vers Java mais pour la reconversion des javaistes ca me parait pas gagné.
En tout cas bravo pour cet œcuménisme.
[^] # Re: Scala ?
Posté par ★★★ ★★ . Évalué à 2.
en termes de performance surement, mais pas en termes de concept. Scala compile dans le meme bytecode que Java. Groovy non. C'est simplement parceque Groovy ne repose pas sur les memes concepts (le fait qu'il soit dynamique change tout). Donc au runtime en introspectant une classe un framework ne sait pas si la classe a ete ecrite en Java ou Scala. C'est un vrai point fort. Il est par exemple possible de debugger du Scala avec un debugger java non prevu pour, ou faire fonctionner des choses comme hibernate sur des classes Scala naturellement.
A propos de play, tu n'as pas nesoin de connaitre groovy. Quand tu ecris un template tu ecris avant tout un fichier HTML (ou XML ou TXT ou ...) et ensuite tu met des parties dynamiques. Au plus simple ${name}. Ensuite effectivement tu peix utiliser quelques operateurs groovy pratiques comme ${name ?: 'guest'}. Mais c'est transparent.
Et tu n'as pas besoin de connaitre Scala. Le support scala et prevu pour la 1.1 et sera optionel. Juste pour ceux qui veulent essayer une syntaxe qui devrait etre plus concise.
[^] # Re: Scala ?
Posté par nomorepost . Évalué à 2.
Je comprend mieux vos choix de technos.
Pour les templates, vous n'auriez pas souhaité réutiliser les GSP de Grails ?
[^] # Re: Scala ?
Posté par ★★★ ★★ . Évalué à 1.
La GSP pour laquelle on doit se rabattre sur le code compilé pour trouver l'erreur ça ne m'a pas emballé.
[^] # Re: Scala ?
Posté par reno . Évalué à 4.
>
>Ca fait longtemps que ca existe les langages multiparadigmes: fonctionnel+objet+impératif
Ce n'est pas Vendredi alors je vais essayer de repondre sans generer de troll (mission impossible). Deja par rapport a tous les autres langage que tu propose Scala a l'avantage de pouvoir acceder facilement au code Java existant.
Plus specifiquement:
-Par rapport a CLOS, ScmObj (Scheme): Scala a pour avantage sa syntaxe, celle de Lisp/Scheme n'est pas tres populaire..
-Par rapport a CLOS, ScmObj (Scheme),Ruby: Scala a pour avantage
1) typage statique avec inference locale, ce qui permet de n'avoir pas beaucoup plus de declaration de type tout en gardant une securite supplementaire
2) les performances (quasiment les memes que celle de Java).
-Par rapport a Ocaml, je dirais que l'avantage principal c'est d'etre un vrai mix fonctionnel / objet+imperatif alors qu'Ocaml est aborde principalement par son cote fonctionnel, au moins dans le manuel que j'avais lu..
[^] # Re: Scala ?
Posté par nomorepost . Évalué à 3.
J'ai l'impression que Groovy a une syntaxe quand même plus Javalike que Scala et il permet simplement de fait de la programmation fonctionnelle.
[^] # Re: Scala ?
Posté par benoar . Évalué à 3.
Le mieux pour comprendre, selon moi, est d'aller voie les exemples avancés :
http://www.scala-lang.org/node/44
# il est malheureusement connu pour sa faible productivité ...
Posté par syj . Évalué à 4.
Si tout est bien Serialisable. La modification est appliqué sans redémarrage et sans perte de session même dans une application Statefull :) et tout cela depuis des années.
Les exceptions qui sont levées et qui apparaissent dans la console. Il me suffit de cliquer pour savoir quel fichier est incriminé.
Je crois même que je peux toucher au mapping Hibernate sans que çà change.
On peut même arrêter le serveur et récupérer ma session complète de manière transparente.
Je peux même profiter de cette fonctionnalité dans le cadre d'un cluster de Tomcat pour assurer la continuité de service.
Tout çà sans faire rien d'autre que d'utiliser Tomcat. ...
Pour moi, la création de WAR n'apparaît que dans la phase de mise en production via déploiement du war.
# Ne nous fâchons pas...
Posté par André Rodier . Évalué à 1.
Est-ce que la fonction "edit and continue" est implémentée ?
Pour ceux qui n'ont pas la chance de connaître, cela permet de modifier le code au cours de la phase dedébogage. Avec les fonctions "Set next statement", cela permet de faire à peu près ce qu'on veut.
PS. Je parle de VisualStudio et de C# (saymal©)
[^] # Re: Ne nous fâchons pas...
Posté par syj . Évalué à 1.
Pour les novices en Java, le temps du rechargement leur permet de méditer sur leur erreur afin d' être meilleures la prochaines fois.
Voila pourquoi les projets Java sont de très bonne qualité :)
Plus sérieusement pour Play, je ne sais pas mais la modification de code pendant une session de debug sous eclipse peut marcher si elle est limité ... De souvenir, c'est comme si tu redémarrais la fonction.
J'aime pas ce genre de gadget car tu peux très vite arriver sur des situations où tu te confrontes à des bugs ou des problèmes qui sont du à ces mises à jour en continu et perdre du temps sur quelques choses qui normalement est censé t'en faire gagner.
[^] # Re: Ne nous fâchons pas...
Posté par ★★★ ★★ . Évalué à 1.
# ServerSide
Posté par nomorepost . Évalué à 2.
http://www.theserverside.com/news/thread.tss?thread_id=58270
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.