Sa conclusion, en simple : J2EE et Jboss sucks grave et sont pas du tout amusant. Les 3 frameworks python et RoR rocks grave et sont super « funny ».
…
Pourtant question simplicité, je trouve pas zope très fun. Leur site donne plutôt envie de s’enfuir quand on le lit, alors que celui de django propose un tutorial ultra-simple pour installer et développer sa 1ere appli django (et pas besoin de cliquer partout sur le site pour le trouver, ce tutorial), qui donne vraiment envie d’aller plus loin.
…
Seam est un framework web, comme l’est RoR, Django ou TurboGears. Plone pour moi c’est encore une autre histoire : c’est déjà un CMS complet !
Seam est du genre RoR : création rapide de projet, création de vue, création automatique d’un squelette d’appli à partir d’une base de donnée, etc …
Si on utilise seam-gen, que l’on utilise la base de donnée préconfigurée, je pense qu’on est très proche d’un RoR.
C’est fun de créer une appli web avec Seam … avec J2EE *brut*, c’est du suicide !
…
Essai seam, c’est vraiment bon ! Je ne pourrais plus jamais faire du J2EE pur.
Il y a un forum assez actif et la doc est conséquente. Tu peux avoir du support commercial si tu en as besoin (mais on peut très bien faire sans).
…
Il n’y a qu’une chose qui me manque actuellement mais qui arrive bientôt : la gestion de la sécurité. C’est prévu pour la version 1.5 pour dans quelques semaines.
Bon bien sur, faut aimer le java. Ca utilise notamment pas mal les annotations (je trouve ca plutôt sympa).
Si non, c’est vrai que plone en tant que CMS, c’est vraiment puissant, j’aime bien …
…
Je suppose que tu voulais parler de Django http://www.djangoproject.com/
Sinon mon avis rapide:
– JEE c’est effectivement lourd, mais une fois qu’on maîtrise, on peut coder quasiment sans réfléchir (ce qui n’est pas drôle en fait…) :
Le problème c’est que les API sont souvent « over engineered », c’est concu pour résoudre tous les problèmes, y compris ceux dont la chance de rencontre est quasi nulle.
Une petite parenthèse, Spring simplifie plutôt les chose dans ce domaine, au contraire de ce que tu semble penser en employant le terme « joyeuseté »
– Zope: j’ai essayé très brièvement, et ça ne m’a pas vraiment séduit, mais je regarderai la video dès que je serai de retour chez moi 😉
– Django, RoR, et Turbogears sont tous les trois de très bons frameworks. J’ai une préférence pour Turbogears et Django, principalement pour des raison de lisibilité du code (AMA pour un développement en équipe Python est un meilleur choix que Ruby au niveau lisibilité), mais surtout pour la documentation.
…
pour info: il ne parle pas de django pour python, ni de zope, mais de Plone qui est un cms tres complet par dessus zope (mais pas tout a fait un framework a mon avis)
la video est assez ancienne, et django etait preque inconnu à l’époque
Pour ceux que ca interesse, aujourd’hui les framework web efficaces, puissants et fun sont django et rails
perso je m’interesse plutot a django, quelques lien: www.djangoproject.com
premiers pas en django si vous causez pas english:
http://www.biologeek.com/journal/index.php/traduction-franca(…)
la meme chose et bien plus en anglais sur http://www.djangoproject/documentation
le livre en cc ecrit par les auteurs de django
http://www.djangobook.com
la version 1.0 de django va arriver dans quelques semaines
son test est pas super je trouve, mais il met en evidence la difficulté de faire des choses rapidement et simplement en java.
ce qu’il fait avec plone est discutable je trouve… mais bo
http://www.django-fr.org/
. ..
Pour me situer, je dirais que j’ai fais et je fais toujours pas mal d’applis en PHP. J’ai utilisé Zope avec CPS (gestion documentaire en gros), et développé des produits dessus. Je connais RoR de nom et vois à peu près la simplicité.
J’ai récemment utilisé le framework Symfony (PHP) qui s’approche de RoR et je me met à J2EE par JBoss/Seam et les EJB3.
Commençons par Zope. C’est un serveur d’appli en python qui à mon sens vieillit un peu. Ca fait quelques années qu’ils comptent généraliser Zope3, mais force est de constater que ça prend pas. Le gros problème avec Zope c’est pour le déploiement.
Tu fais des modifs dans la ZMI (Zope Management Interface) en interface Web, mais pour packager le tout, il faut bien faire des produits en Python, redéployer, redémarrer le serveur etc… Les IDE ne sont pas légion. Nuxeo, la société qui développe CPS (sous Zope) a récemment migré la solution sous Jboss/J2EE, ils donnent les raisons sur leur site.
Je vais parler de Symfony qui est à mon avis un très bon Framework en PHP, qui se veut l’équivalent de RoR pour PHP. J’ai beaucoup aimé le découpage en module, l’ORM (object relational mapper), le routing utilisé avec le Path info… Enfin la doc est très bien foutue, en une après midi, j’avais finie ma première appli avec support Ajax etc… La seule réserve est sur les performances avec la montée en charge que je ne peux pas trop mesurer pour l’instant mais 300ms pour servir une page en mode Debug je trouve ça beaucoup.
Enfin, la dernière techno à laquelle je me mets, J2EE/Jboss. J’avais essayé il y a quelques années, mais j’avais trouvé ça énormément lourd en terme de configuration. Pour afficher une simple table avec des Beans, il fallait je sais pas combien de fichiers de conf….
EJB3 semble changer la donne et tirer parti des avantages de Java5. C’est beaucoup (beaucoup) plus simple à configurer et à lire. Le framework Seam propose un petit utilitaire qui crée automatiquement un projet Eclipse et les première vues, il n’y a plus qu’à mettre un peu de code pour tes bean et ça fonctionne pas trop mal. Seam enlève en plus la lourdeur des managed beans et ajoute pas mal de facilité (gestion des workflow métiers etc…)
Ca semble lourd et comme il a été dit précédemment c’est un peu over-engineeré dans le sens où tout a été prévu pour beaucoup de cas. Je pense que pour de très grosses applications où ça communique beaucoup, l’architecture EJB est très intéressante. C’est très facile de faire des WebServices, et des frameworks Ajax s’intègrent plutot bien dedans.
L’autre avantage que je vois c’est la standardisation de certaines pratiques via les JSR. Par exemple les JSR sur les portlets. Si je fais un appli qui implémente cette JSR (168 il me semble), ça me permet d’inclure cette appli dans tout portail gérant cette spécification. Au fur et à mesure, ça permet d’intégrer des modules parlant ensemble (on peut inclure des portlets codés en PHP ou autre je crois…)
Mon impression globale, c’est que pour une application relativement autonome, je choisirais des framework du type de RoR (j’inclue Symfony) et pour des plus grosses applications il me semble (j’en ai absolument pas la certitude) que J2EE apporte des fonctionnalités de scalabilité que n’ont pas PHP ou Python. En PHP par exemple, ton application recommence à chaque requête de zéro. Il faut réinstancier les composants essentiels, réévaluer le contexte etc…. Avec J2EE, les objets restent « vivants » sur le serveur et du coup le contexte applicatif ne se recharge pas à chaque requête.
Ce ne sont que des impressions, je peux bien sur me tromper. Autant je connais très bien PHP, autant je débute avec les EJB. L’impression que j’ai c’est qu’il se sont quand même grandement améliorés.
….
Je n’ai jamais utilisé de framework Python à part une petite expérience avec Zope, j’ai pas trop apprécié l’interface d’admin un peu déroutante pour les débutants. Puis j’ai eu une expérience avec J2EE+Springs et j’ai trouvé ça plutôt lourd, compliqué mais bien architecturé et structuré.
Vu que je n’avais que de l’expérience en PHP de base, j’ai apprécié ce dernier point. J’ai cru un instant qu’il n’existait pas de framework qui puisse allier la rapidité, la facilité et la souplesse de PHP avec les avantages de J2EE sans les inconvénients.
Après j’ai effectué un stage de licence où j’ai développé des petites applis internes en PHP 5 avec les bibliothèques PEAR et ça m’a plu. Enfin un peu de développement rapide en PHP, sans perdre de temps avec la validation des formulaires, l’accès au BdD (ORM simple), etc. Mais ce n’était toujours pas structuré, « cadré ».
En faisant des recherches sur PEAR, je suis tombé par hasard sur le site de Ruby on Rails et ça a été très rapidement le coup de foudre ;).
Ce que j’ai fait : j’ai très rapidement acheté le livre « Agile Web Development with Rails » écrit par les développeurs de RoR.
J’ai lu beaucoup de livres informatiques, mais rarement un livre aussi bien écrit. J’étais littéralement scotché par ce livre, par sa manière de présenter le framework RoR, le faire découvrir à des développeurs dont la plupart n’ont jamais développé en Ruby, sa philosophie de développement (méthode « agile »), ses touches d’humour… Un livre extrêmement complet, couvrant tout le développement d’une application Web, de la conception sous forme de schéma, le développement, l’AJAX, les Webservices (REST), la sécurité, jusqu’au déployement.
C’est simple, que vous veniez de Java, d’un autre framework ou que vous soyez simple développeur amateur PHP, procurez-vous ce livre en version PDF et/ou papier, vous ne regreterez pas.
http://www.pragmaticprogrammer.com/titles/rails/index.html
Bon fini la pub, j’ai pas d’actions chez eux :-).
Si vous voulez avoir une belle et courte introduction gratuite de ce framework, je vous conseille ce beau PDF en français :
http://people.no-distance.net/ol/documents/rails-intro/rails(…)
Je développe aujourd’hui qu’avec Ruby on Rails, je me considère encore comme un débutant, j’en apprends tous les jours, je suis souvent étonné par certains points, par l’aspect « magique » de ce framework (bien que rien ne soit magique, mais j’adore le côté Convention over Configuration). Je trouve la documentation de l’API vraiment « pro » et proche des docs d’un logiciel d’entreprise (http://api.rubyonrails.org) alors que la doc de certains frameworks ressemblent plus à du wiki.
J’adore la manière de créer des formulaires autour d’un objet relié à une base, la validation, le mappeur BdD objet vraiment très complet, dynamique et compatible avec tous les SGBD connus (y compris Oracle et MS SQL Server), la gestion de l’AJAX et les vues RJS qui permettent d’utiliser Script.aculo.us et ses effets entièrement en Ruby, les nouveautés de Rails 1.2 : gestion parfaite de REST, ActiveResource…
Sans compter que le futur de Ruby on Rails est rose : Ruby 2 va arriver avec une belle explosion des performances (Ruby n’aura plus à craindre les benchmarks contre PHP et Python) et Mongrel, le mini serveur Ruby avance vite et permet de développer ET déployer en prod des applications Rails à vitesse grand V.
….
Je n’ai jamais utilisé de framework Python à part une petite expérience avec Zope, j’ai pas trop apprécié l’interface d’admin un peu déroutante pour les débutants. Puis j’ai eu une expérience avec J2EE+Springs et j’ai trouvé ça plutôt lourd, compliqué mais bien architecturé et structuré.
Vu que je n’avais que de l’expérience en PHP de base, j’ai apprécié ce dernier point. J’ai cru un instant qu’il n’existait pas de framework qui puisse allier la rapidité, la facilité et la souplesse de PHP avec les avantages de J2EE sans les inconvénients.
Après j’ai effectué un stage de licence où j’ai développé des petites applis internes en PHP 5 avec les bibliothèques PEAR et ça m’a plu. Enfin un peu de développement rapide en PHP, sans perdre de temps avec la validation des formulaires, l’accès au BdD (ORM simple), etc. Mais ce n’était toujours pas structuré, « cadré ».
En faisant des recherches sur PEAR, je suis tombé par hasard sur le site de Ruby on Rails et ça a été très rapidement le coup de foudre ;).
Ce que j’ai fait : j’ai très rapidement acheté le livre « Agile Web Development with Rails » écrit par les développeurs de RoR.
J’ai lu beaucoup de livres informatiques, mais rarement un livre aussi bien écrit. J’étais littéralement scotché par ce livre, par sa manière de présenter le framework RoR, le faire découvrir à des développeurs dont la plupart n’ont jamais développé en Ruby, sa philosophie de développement (méthode « agile »), ses touches d’humour… Un livre extrêmement complet, couvrant tout le développement d’une application Web, de la conception sous forme de schéma, le développement, l’AJAX, les Webservices (REST), la sécurité, jusqu’au déployement.
C’est simple, que vous veniez de Java, d’un autre framework ou que vous soyez simple développeur amateur PHP, procurez-vous ce livre en version PDF et/ou papier, vous ne regreterez pas.
http://www.pragmaticprogrammer.com/titles/rails/index.html
Bon fini la pub, j’ai pas d’actions chez eux :-).
Si vous voulez avoir une belle et courte introduction gratuite de ce framework, je vous conseille ce beau PDF en français :
http://people.no-distance.net/ol/documents/rails-intro/rails(…)
Je développe aujourd’hui qu’avec Ruby on Rails, je me considère encore comme un débutant, j’en apprends tous les jours, je suis souvent étonné par certains points, par l’aspect « magique » de ce framework (bien que rien ne soit magique, mais j’adore le côté Convention over Configuration). Je trouve la documentation de l’API vraiment « pro » et proche des docs d’un logiciel d’entreprise (http://api.rubyonrails.org) alors que la doc de certains frameworks ressemblent plus à du wiki.
J’adore la manière de créer des formulaires autour d’un objet relié à une base, la validation, le mappeur BdD objet vraiment très complet, dynamique et compatible avec tous les SGBD connus (y compris Oracle et MS SQL Server), la gestion de l’AJAX et les vues RJS qui permettent d’utiliser Script.aculo.us et ses effets entièrement en Ruby, les nouveautés de Rails 1.2 : gestion parfaite de REST, ActiveResource…
Sans compter que le futur de Ruby on Rails est rose : Ruby 2 va arriver avec une belle explosion des performances (Ruby n’aura plus à craindre les benchmarks contre PHP et Python) et Mongrel, le mini serveur Ruby avance vite et permet de développer ET déployer en prod des applications Rails à vitesse grand V.
….
Exactement. Dans Rails 1.2 (REST), Rails peut directement fournir au client du XML, HTML, etc selon la requete.
Ce qui est tueur dans Rails 1.2 c’est d’associer l’application RESTful avec le plugin ActiveResource.
ActiveResource reprend un certain nombre des fonctions du mappeur BdD objet ActiveRecord comme find, delete, etc. En faisant un find(1) il va automatiquement aller fetcher le XML correspondant et l’intégrer dans un objet.
Au final, on a une abstraction complète de la source des données (qui peut etre un SGBD en local ou un serveur Web au Japon) tout en utilisant des technologies ultra-standard (XML et HTTP).
Exemple tout bête :
employe = Employe.find(1)
employe.prenom ==> « Nicolas »
Si Employe est un objet ActiveRecord, en backoffice on a un SELECT dans une base quelconque puis un mapping objet.
Si Employe est un objet ActiveResource, en backoffice on a un fetch http://serveur_distant/employes/1 qui va retourner un XML puis un mapping objet.
On peut meme gérer la suppression d’enregistrement, l’édition, etc, avec possibilité de gérer une authentification à distance via HTTP(S) Auth.
Vraiment très bien pensé, absolument simple et efficace.
Et pour ceux qui trouvent ça déjà avancé, ne vous inquiétez pas, Rails est aussi génial pour faire des choses basiques : formulaires HTML, accès aux bases, etc…
…
globalement on est donc tous d’accord avec la conclusion de la vidéo. Même si c’est vrai qu’elle ne compare pas les bonnes choses.
A mon avis, le bon comparatif serait :
Rails / Django / Turbogears / Grok (qui arrive lentement)/ Seam/Java ?
et :
Zope3 / J2EE
(Quant à Zope2 il a toujours été un peu à part et ne compte plus vraiment.)
Et je ne sais pas quels seraient les équivalents dans le monde microsoft.
pvergain.wordpress.com 