★★★ ★★ a écrit 17 commentaires

> ... çà va de supprimer la barre utilisateur ...

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.

Ca permet probablement de profiter des fonctionnalités d'eclipse mais pas de profiter pleinement de l'architecture du Web. Le Web est une architecture Stateless et RESTFul. A mon avis essayer d'aller a l'encontre de ce fait pose plus de problèmes qu'il n'en resout (bouton Back ?)

Oui ca fonctionne avec un debugger JPDA (par exemple celui de eclipse ou netbeans). Lorsque play demarre en mode DEV il ecoute automatiquement sur un port JPDA pour des sessions de debuggage.

Les locks sur les repertoires ? Tu veux dire cette limitation de windows alors. Je crois que vraiment le feeling de developement ca se ressent plus que ca s'explique. Tu devrais essayer les tutoriel pour voir comment ca se comporte.

> Le hotswap marche très bien dans Tomcat.

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é.

La plus grosse fonctionnalité du moteur de template c'est de dire précisément ce qui se passe et là où ça a planté en cas d'erreur.

La GSP pour laquelle on doit se rabattre sur le code compilé pour trouver l'erreur ça ne m'a pas emballé.

> C'est un point qui peut s'améliorer

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.

Effectivement pour play l'intégration de Scala est naturelle car Scala est juste un successeur de Java.

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.

Le rechargement dans tomcat est plutôt primaire et ne prend pas en compte les spécifités de l'application.

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...

La majorité des contributeurs du projet font partie de zenexity. Nous l'utilisons pour la plupart de nos projets. Mais l'équipe de développement s'est ouverte à des contributeurs externes n'ayant aucun rapport avec zenexity (3 membres actuellement).

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.

En fait Play! et Wicket ne font pas exactement la même chose. Si dans les 2 cas le but est de créer une application Web les style d'architecture sont complètement différents.

Wicket a un modèle statefull dans lequel chaque page est représenté par un modèle objet en mémoire qu'on retrouve de requête en requête et qu'on manipule de manière complètement objet. En gros Wicket c'est JSF correctement implémenté.

Play! est un framework purement stateless, dans lequel chaque requête est complètement indépendantedes autres. C'est le même modèle que les frameworks type Rails, Django ou Symphony.

Je pense pour ma part que le modèle de framework stateless est bien mieux adapté au Web, notamment parceque HTTP lui même est stateless. La gestion du bouton back, du refresh, du load balancing sont des problèmes difficiles à résoudre avec un framework statefull. Mais il faut bien avouer que les développeurs de Wicket font un excellent travail en essayant de régler tous ces problèmes au niveau du framework pour soulager les développeurs. Bon évidemment avec un framework stateless on n'a pas à les régler car c'est fait par construction.

Alors après c'est une question de goût entre les 2 architectures ....

Par contre le cycle de développement avec Play! est bien plus agréable avec le rechargement transparent des modifications et de bons rapports d'erreurs.

Et sinon http://www.playframework.org/manual/contents/fivecoolthings .

C'est vrai. Et ça a longtemps été un dilemme. Mais finalement si on veut faire quelque chose de plus simple que le J2EE standard finalement on est bien obligé de faire ce choix.

Et en forçant un peu on peut quand même plus facilement convaincre un client qui a tout en J2EE d'utiliser un framework Java même si les APIs ne sont pas les mêmes que d'habitude, plutôt que de le convaincre d'utiliser un nouveau langage. Utiliser un nouveau langage ça change beaucoup de chose pour une équipe de développement. Là avec Play! on peut quand même capitaliser sur les compétences Java des développeurs, les IDEs (Netbeans ou Eclipse) les libs Java internes, une partie de l'infra d'execution ....

En plus on commence à voir quelques solutions Java dites "entreprise" qui s'éloignent de plus en plus de J2EE. Par exemple le Spring application Server ( http://www.springsource.com/products/suite/applicationplatfo(...) ), ou Websphere Smash ( http://www.projectzero.org/ ).

Pour moi si Java a une chance de s'en tirer c'est sans les piles J2EE historiques qui n'ont rien compris au Web ...

Effectivement le but n'est pas de troller sur Java vs. Python. En plus c'est une discussion sans fin.

Mais disons que personnellement juste au niveau langage, je trouve que Python et bien plus puissant et plus riche que Java. Après ça peut être un avantage ou un inconvénient... suivant dans les mains de qui on met le langage ...

Par exemple des choses qui sont très simple à implementer en Python comme retrouver le nom des variables locales ou binder directement les données HTTP aux paramètres de fonction ont été un casse tête à implémenter en Java. Mais avec de la manipulation de byteCode et un peu de magie noire ont s'en sort toujours ...

C'est vrai que Play! s'inspire franchement des frameworks que sont RubyOnRails ou Django. Mais Play! est un framework Java et des fois c'est important.

Je ne suis pas un intégriste Java et franchement si j'ai le choix je préfère travailler en Python qui est clairement un langage bien meilleur. Mais souvent on n'a pas le choix car Java est un langage très utilisé surtout dans le monde professionnel. Donc on avait vraiment besoin d'avoir un framework Java à la hauteur.

Après il faut être honnête, si Java a des défauts par rapport aux langages dynamiques style Ruby ou Python, il a aussi ses avantages : un excellent eco-système OpenSoure, de bons outils de développement, le typage statique n'a pas que des inconvénients (détection de nombreux problèmes à la compilation), excellents debuggeurs, excellente virtual machine et performances ...

Donc Play! ne s'oppose pas directement à RubyOnRails ou Django mais si vous devez développer en Java c'est une piste à explorer sérieusement ....

Oui on utilise le compilateur d'eclipse car il est facilement "embeddable". Mais c'est la chose que nous utilisons d'eclipse et pour l'instant Play! n'a aucun rapport avec OSGI (même si je vois bien l'idée au niveau de l'extensibilité du framework par module, mais pour l'instant nous avons un système d'extension très simple qui rempli parfaitement son rôle).

Dans le cas classique la génération d'une page se fait effectivement en mémoire. Pour des gros contenus, Play! passe par un mode spécial où le contenu est d'abord écrit sur disque. Puis le worker HTTP se débrouille pour l'envoyer sur le réseau ensuite.

L'upload de gros fichiers ne pose aucun problème. Le fichier envoyé est d'abord écris sur disque avant d'être passé à l'application qui peut le manipuler comme elle veux.

Au sujet du langage de template, nous avions besoin d'avoir complètement la main sur la syntaxe et les possibilités. Nous avons donc réécris un langage de template ad-hoc. Mais pour ne pas repartir de trop bas, nous avons utilisé groovy comme langage de base. C'est également très facile d'implementer un langage à base de tag en utilisant les closures de groovy. Au final parser+compiler+renderer ne depassent pas quelques centaines de lignes de code ...

Tu n'as pas à installer un tomcat ou un jboss toi même. La demo d'alfresco inclus le tomcat ou le jboss suivant celui que tu télécharge. Dans les 2 cas c'est le même alfresco. Mais si tu télécharge la version JBoss (en fait il s'agit de JBoss portal) alfresco est livré sous forme d'un portlet (ce qui n'a aucun interêt puisque toute l'application n'est qu'un enorme portlet).

Tout ce dont tu as besoin est une JVM 5.0 (je te conseille celle de sun http://java.sun.com)(...) et une base mysql (et optionnellement open-office 2.0 pour certaines fonctionnalités).

Tu trouve les scripts d'initialisation de la base de donnée avec alfresco.

Au pire tu as juste besoin de définir les variables d'environnement JAVA_HOME, TOMCAT_HOME, ou JBOSS_HOME.

Ensuite tu démarre le jboss ou le tomcat avec le script sh correspondant.