Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
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.Envoyé par romaintaz
A+
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 ?
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.
Oui on est d'accord, mais ça n'empêche pas de coder par exemple l'interface d'administration en client lourd.
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'accordMais en fait ce que je me demandais c'était surtout sur les moyens de communication avec une vue swing:
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
Oui, tu as désormais 2 programmes nommés "play" dans ton PATH.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
play est aussi le nom d'un programme du package sox, qui est en premier dans le PATH.
@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
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
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.
Application server ?
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.
Quelques remarques
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.
Répondre avec citation
Partager