Il y a un nouveau framework: "Play" (http://www.playframework.org/).
Que pensez-vous?
Version imprimable
Il y a un nouveau framework: "Play" (http://www.playframework.org/).
Que pensez-vous?
Personnellement j'ai developpé un petit blog en me basant sur le tutorial, et c'est tout simplement genial ;)
C'est très simple alors que j'ai jamais utilisé J2EE, je compte l'utiliser pour remplacer Django et Rails, car je le trouve bien plus sympa et "pro", puis j'adore le Java.
Je suis justement en train de m'y essayer, après avoir succinctement testé Grails, OpenXava.
Pour le moment, je le préfère. Je trouve l'URL binding au POJOs, vraiment intuitif, le routage des URLs et puis ça reste Java.
Et Play semble pouvoir s'adapter à pas mal de problématiques, pas seulement du CRUD.
Pour le moment, avec Grails devoir faire du groovy me pertube un peu, d'autant que je connais déjà JPA.
Et en développant en Grails, fallait que j'apprenne GROM, je me suis retrouvé à faire du javascript, ce que préfère éviter. Pourtant, il y a plein de plugins sympa avec grails (datasources, security).
Mais, même si j'analyse pas trop pourquoi, mais je progresse plus vite avec Play.
OpenXava est aussi basé sur JPA+annotations orientés pour faire du CRUD, avec pas mal de boulot pré-machées (filtres, recherche, export Excel/PDF, voir jasperReport). On peut même décrire l'affichage des tableau & formulaire via les annotation au niveau des entités.
Le projets avait l'air un peu rouillé quand je me suis penché dessus. Il fallait redémarrer le conteneur de servlet à chaque changement. J'ai pas trouvé bcp de ressource pour ajouter une couche de sécurité alors j'ai eu envie de testé des techno plus jeune.
Mais une version majeur vient de sortir, la 4 :
http://www.openxava.org/web/guest/changelog
Sinon, j'ai entendu parlé d'aribaweb, mais j'ai pas eu l'occaz de le tester.
J'avais jeté un coup d'oeil ...
Il y a des trucs sympa ...
Mais comme j'avais l'impression qu'il est développé et maintenu par un seul type, je suis pas allé plus loin ...
Bah c'est un projet tout jeune encore, ils sont quelques uns : https://launchpad.net/~play-developers
Je suis toujours aussi content ce framework, j'ai ajouté une couche de confidentialité avec LDAP en tout au plus 10 lignes.
Ma foi je suis bleuffé, ca faisait un moment que j'attendais un bon outil RAD orienté Web en Java. Je vais le tester sur un nouveau projet.
j'ai jeté un coup d'oeil et ça m'a semblé hyper intéressant. j'avais déjà regardé grails mais même si j'aime bien groovy, la compilation du java me rassure pour corriger des bugs de saisie.
donc un rails en java me plait bien. et puis je trouve ce framework très léger, largement suffisant pour la plupart des cas. je vais faire quelques appli en test pour mieux l'évaluer
Il me semble plus pertinent de splitter le projet en une bibliothèque de scripts de génération de code, et une autre de fonctionnalités.
Ce serait par exemple bien de pouvoir utiliser le système de routage independamment du reste.
Trop de frameworks tue le framework :p
@morbo
Relis ton message en faisant comme si tu ne connaissais pas les noms des frameworks et des technos citées, ça fait peur le monde du dévelopement web, hein ? :mrgreen: (moi je staïk, sur mon flex !)
J'avoue :p (Tout le monde est sur son flex?!)
Intéressant, comme framework, j'avais mis de côté Java, struts et spring en faveur de Ruby on rails.
Je vais me lancer dans un petit projet pour tester.
Essaye JaxRS + JPA sur des entities ;)Citation:
Envoyé par helix_tp
Bon je viens de tester, j'ai repris les samples et enrichi l'un d'entre eux et c'est vraiment excellent.
Super rapide, intuitif, très agréable à développer dessus. C'est sur, je vais continuer a jouer avec. Je doute pouvoir l'insérer en entreprise pour l'instant par contre, un peu jeune.
Et c'est ca qui va limiter. En entreprise il faudra être culotté pour le proposer, et pour du perso il faut un hébergeur Java donc ca limite tout de suite un peu. Mais j'aime beaucoup, je vais le pousser un peu.
Ouaip, je reste très content également, je vais continuer à le pousser de mon coté. Pour des petites appli de gestion c'est ideal.
Ce qui est très agréable, c'est la courbe d'apprentissage de ce framework, très douce. J'ai commencé par une appli toute simple, puis ajouté un Crud, de la conf basique, puis fait évoluer chacun des maillons au fur & à mesure que j'affinais ma compréhension.
Très simple de se faire ses propres modules adaptés à ses besoins, les montées de version passent comme une lettre à la poste.
Guillaume le "main" développeur est très très réactif sur le forum.
C'est mon gros coup de coeur de cette fin d'année.
Un petit retour de plus :
http://www.grantklopper.com/2009/12/...d-why-you.html
Pour le coup j'ai ajouté un billet dessus :
http://hakanai.free.fr/index.php/the-news/58-play
Pour les personnes intéressées, j'ai traduit le guide de création d'un blog avec Play ici : http://linsolas.developpez.com/artic...va/play/guide/
petite question par rapport à l'installation.
J'ai décompressé le répertoire play 1.0.1, j'ai bien mis la varial PATH à jour.
Quand je tape play dans la console (ubuntu) il ne fonctionne pas, il me parle de sox ect ... quelqu'un à une idée ???
Merci :ccool:
Il faut une version de python installée sous Linux.
Sinon un retour détaillé sur Play au JUG de Genève est là :
http://waves.inagua.ch/2010/01/26/le-jug-geneva-play/
Il y a un nouveau site communautaire de bonnes pratiques & astuces pour Play! qui a vu le jour : http://cuisine.reelance.com/
Au fait, le répertoire de modules communautaires est en place pour la version de développement (la 1.1) et bientôt pour la version stable 1.0.2.
Il y a déjà pas mal de modules intéressant comme un module de PDF (basé sur YAHP) qui permet assez facilement d'avoir des pdf de ses pages html.
Il y a aussi un moteur de rendu purement java (plutôt que groovy) si on a besoin de meilleurs perfs ou pas l'envie de faire du groovy.
Egalement un module d'authentification via un "OAuth provider" comme google, twitter, ...
J'ai gouté à struts 1, struts 2, spring mvc, DTO/DAO, EJB 2.0,3.0 ....
Enfin un petit framework innovant qui change des usines à gaz J2EE/JEE :)
Keep it simple !
En revanche j'ai pas trop creusé encore, mais quid de l'intégration avec client lourd type swing ?
Merci, c'est très sympa. :ccool:Citation:
Envoyé par romaintaz
A+ ;)
Citation:
Envoyé par Mens Pervincet
Play c'est pour du web, donc je ne vois pas quel type d'intégration tu attends ?
Avec Play, c'est très facile de faire du REST.
Il est donc possible de ne coder que les "controllers" et le modèle de donnée coté play.
Le client (lourd ou pas) ne fera alors que des appels à des WS REST (de l'HTTP).
Cela dit, c'est bien plus simple de faire l'affichage en web hein :aie:.
Oui on est d'accord, mais ça n'empêche pas de coder par exemple l'interface d'administration en client lourd.Citation:
Envoyé par hugo123
Pour être plus précis, en JEE "classique" la communication entre un client swing et le serveur se fait généralement via le protocole RMI ( Remote Method Invocation) et avec JMS pour les évenements asynchrones reçus de l'application. C'est assez puissant dans le sens où l'on peut invoquer n'importe qu'elle méthode de nos beans en 4/5 lignes de code.
D'accord :) Mais en fait ce que je me demandais c'était surtout sur les moyens de communication avec une vue swing:Citation:
Envoyé par Morbo
Par exemple y a t il un équivalent du JMS pour notifier de manière asynchrone la vue swing d'un changement d'état du modèle? ( ou bien est ce que ça va à l'encontre de la philosophie Restfull ) ?
( ça revient à demander s' y a -t-il un moyen de faire du vrai MVC avec les clients lourds )
EDIT: en fait on va me dire à juste titre que je cherche la petite bête :aie:, c'est justement parcque le framework me plaît beaucoup que je cherche à en connaître d'éventuelles limites, pour ce qui est de mes besoins.
Oui, tu as désormais 2 programmes nommés "play" dans ton PATH.Citation:
Envoyé par stouf()
play est aussi le nom d'un programme du package sox, qui est en premier dans le PATH. :cfou:
@Mens Pervincet
Il n'y a pas d'intégration à proprement parler avec ce type de technos par contre, il y a deux choses qui peuvent potentiellement t'intéresser :
- activemq est un serveur JMS qui peut utiliser le protocole http en mode REST
http://activemq.apache.org/rest.html
- play intégre l'utilisation de "suspendable requests"
http://www.playframework.org/documen...bs#suspendable
Concernant le second point, il y a une démo sur un chat fait en web dans leur distribution, elle peut t'intéresser.
L'utilisation de REST comme dit par Morbo est pour moi une très bonne alternative, c'est d'ailleurs utilisable dans la même optique quand on fait du GWT
Merci beaucoup ! Ces deux liens sont vraiment tres interessants :ccool:
Bonjour tout le monde !
J'ai découvert play il y a quelque jours par hasard. Je connaissait déjà des framework tel que Grails, Strust en java, mais surtout yii que j'utilise en php.
Play représente pour moi le meilleures de tout cela. Simple, Rapide et Extensible. Je le conseil vivement
Toujours à propos de l'architecture REST avec Play! :
http://coffeebean.loicdescotte.com/2...avec-play.html
Bonjour.
Je me permet de rajouter mon retour d'expérience sur l'outil PLAY.
J'ai étudié ce framework en vu du remplacement d'un outil de développement rapide que nous utilisons dans notre équipe ainsi que pour un mémoire de fin d'étude d'architect logiciel.
J'ai réalisé un portage de deux applications ainsi que simuler un BPEL pour appeller un service SOA et ensuite un service RESTFUL. Les 3 projets réalisés avec PLAY.
La rapidité de prise en main :
La possibilité de convertir son projet sous son ide est un plus incontestable. Pas la peine de perdre du temps à se familiariser avec un environnement de production autre que celui habituel.
L'arborescence n'est pas "fouillis" et on repère assez facilement la logique de conception et de localisation de chaque ressource.
La configuration : tout est pensé pour le développeur. La facilité de déclarer les modules complémentaires, le paramétrage serveur, le lancement, la version de production... rapide et efficace.
La création côté données et métier :
Alors je pense que c'est le gros atout de PLAY! : La facilité de faire un Mapping Objet avec tous les avantages de JPA. L'accélération fournie par les tags permet de se concentrer sur l'aspect donnée sans prise de tête sur le code.
Seulement il faut prévoir un peu de temps pour appréhender la logique play surtout quand on est habitué à n'avoir des classes entité qu'avec des attributs et sans méthodes (souvent délégué à des couches métier pour faire toutes les vérifications).
La création côté vue :
La encore c'est avec une facilité et une efficacité déconcertante que tout est mis en place. Déclarer ses services devient presque addictif :mouarf:
Mais c'est aussi pour moi le point noir de PLAY! :
En temps qu'outil de développement rapide je m'attendais à avoir une solution efficace pour gérer simplement les actions utilisateurs sur les ressources (un peu à la Léonardi pour ceux qui connaissent). Pourvoir déclarer un bouton "Créer" qu'on lierait à une ressource et qui se chargerais de proposer une solution pour saisir les données (avec la possibilité d'autoriser la visibilité de l'action en fonction de paramètres), etc.
Mais bon même sans ca c'est quand même somme tout assez rapide et simple de jouer avec les vues surtout avec le principe de tag et de Master page.
Les plugins : Rapide à déclarer mais bien souvent mal expliqués ou peu fonctionnel. J'aurais aimé un peu de documentation sur ces sujets
Voila pour mon retour sur cet outil :)
Bonjour à tous,
Ça fait déjà plusieurs mois que j'utilise Play et franchement c'est génial, je ne peux plus m'en passer, essayer c'est l'adopter :)
Je n'ai jamais vu un framework aussi simple et puissant, je n'ai aucun doute qu'il a un bel avenir.
Quel bonheur de ne pas attendre que le serveur redémarre à chaque modification du code :)
Pas besoin d'encoder les caractères accentués dans les fichiers de langues, facilité dans l'envoi de données à la vue, simplification de JPA grâce aux méthodes utilitaires etc...
Vraiment je le conseille à tout le monde.
Je remonte ce post pour une petite interrogation complémentaire, quid du serveur d'application ?
En prod le serveur utilisé par Play est suffisant ? Il est basé sur quel produit existant ?
Est-il préférable de déployer notre appli sur un "vrai" serveur d'application ?
Play peut packager une application en war si besoin.
Il y a cependant des applis qui tournent avec le serveur web de Play (sur playapps.net par exemple)
J'ai vu que Play! pouvait packager.
La question portait en fait sur les pros & cons d'utiliser le serveur d'application de Play (apparemment basé sur JBoss Netty) où un serveur d'application Lambda (Glassfish...)
A vrai dire j'ai la même interrogation pour l'utilisation d'un serveur http frontal, il me semble qu'il y en a également un d'embarqué avec Play!.
Bonjour à tous,
Play utilise Netty (JBoss) comme serveur, l'avantage avec Netty, c'est que c'est beaucoup plus leger que un serveur d'application avec plein de fonctionnalités que nous n'allons jamais utilisé et qui consomme de la mémoire.
Pour info le site web de play utilise le slot de base de playapps.net qui n'utilise que 64 mb pour la jvm et il reçoit dans les 100.000 requêtes par jour.
Je change de sujet, j'ai vraiment trouvé dans le Framework Play ce que je cherchais depuis longtemps dans l'écosystème Java. J'ai très peu de chose à lui reprocher. Ce n'est pas un réquisitoire c'est juste des améliorations que j'aimerais voir venir. Je pars du principe que je suis dans un contexte Web stateless:
1 - Le transtypage demande beaucoup de travail, une variable mal renseignée par un visiteur sera perdue. (exemple: 10.2 || 10,2 || 10,2[space]). J'utilise donc beaucoup de Javascript pour filtrer et nettoyer avant envoi (c'est pas plus mal).
2 - Le routing est un peu rigide, la syntaxe est trop lourde. Il manque le chainage des variables dans URL. (/id/2/sort/name/type/client)
3 - Le Model devrait être indépendant, il se retrouve dans l'application principale. Quand le site est découpé en module ça peut être étrange d'aller sur le Frontend chercher des données quand on travaille sur le CMS. Ca alourdit la syntaxe.
Bravo à l'équipe, c'est super.