Une vidéo longue (30min) et lourde (300Mo) d'une conférence donnée par un gars de la NASA à propos du développement d'une application web avec J2EE, RoR, Zope, Djengo, Turbogears et Jboss.
Cette vidéo m'a littéralement sciée. Bossant depuis 4 mois avec J2EE et Jboss, je dois avouer que tout ce qui est décrit est entièrement véridique et pas du tout exagéré ! (au contraire, il a même pas parlé de Spring et d'autres joyeusetés).
http://oodt.jpl.nasa.gov/better-web-app.mov
(ça vaut le coup de la regarder jusqu'au bout)
Un grand merci à Christophe Combelles pour avoir posté cette vidéo dans la news : http://linuxfr.org/2007/01/24/21956.html . J'ai trouvé qu'elle méritait un journal.
Maintenant, je me pose des questions :
- la démo de 3 minutes là, c'est bien, mais à long terme, pour une "grosse" app, est-ce toujours valable ?
- Jboss est très prisé et utilisé. Je n'arrive toujours pas à comprendre l'intérêt et je trouve cela d'une complexité absolument délirante. L'auteur de la vidéo semble d'accord avec moi. Quel point avons-nous raté ? (ze gros avantage/feature de jboss qui en fait un killer)
- entre zope, django et turbogears, vous choisissez quoi et pourquoi ? des retours d'expériences ? Des remarques de ceux qui en ont utilisé plusieurs d'entre eux ?
- zope semble un peu être le jboss de python. c'est juste une impression que j'ai ou c'est fondé ?
Entre nous, j'aimerais garder la discussion purement technique. Des arguments comme "est bien accepté dans le milieu professionnel", "est fort répandu" ou "existe depuis 10 ans" ne m'intéressent pas. Je prend le cas (fictif ?) d'une nouvelle application développée from scratch, sans donnée précédente, sans contrainte de backward compatibilité pour le moment par des développeurs compétents, sachant lire de la doc.
Journal J2EE vs RoR vs Python
25
jan.
2007
# et sa conclusion ?
Posté par Axel . Évalué à 6.
Merci ploum< .
[^] # Re: et sa conclusion ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Après il y a les détails : le temps passé pour faire la même appli sur chaque framework, la gestion des erreurs, le nombre de problème "prise-de-tête" et surtout la réactivité et la facilité pour visualiser une modif.
D'après sa vidéo, le tout grand gagnant est zope. Le tout grand perdant est Jboss.
si qqn trouve une page récapitulative de sa vidéo, ça peut être très intéressant.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: et sa conclusion ?
Posté par Prosper . Évalué à 10.
[^] # Re: et sa conclusion ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mais, de mon expérience, au niveau perf et maintenance, je ne vois pas physiquement comment on pourrait faire pire que JBoss.
Après, une étude comparée de la scalabilité pourrait être intéressante. Je n'ai encore jamais utilisé ce genre de logiciels sur des projets avec un tel besoin.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: et sa conclusion ?
Posté par Nelis (site web personnel) . Évalué à 8.
Dans la pratique, dans 99% des cas Tomcat suffit (en tout cas pour le dev, après qu'on déploie sur un serveur plus robuste tel que Weblogic, ça ne change rien).
Comparer JBoss et Ruby On Rails c'est comme comparer Apache à RoR ...
[^] # Re: et sa conclusion ?
Posté par Calvin0c7 . Évalué à 2.
Jboss n'est qu'un serveur d'application parmi d'autres, et si ses perfs sont décevante il ne faut pas les lier à J2EE.
Comme dit plus haut dans 99% des cas tomcat suffit. Pour le 1% qui reste il est raisonnable d'envisager un serveur plus robuste comme celui de BEA ou IBM. De là à dire que Jboss ne sert à rien il y a un pas que je ne franchirai pas vu que je ne le connais que de (mauvaise) réputation.
[^] # Re: et sa conclusion ?
Posté par cho7 (site web personnel) . Évalué à 5.
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.
Mais cet avis n'engage que moi...
[^] # Re: et sa conclusion ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Cependant, à l'usage, peut-être que zop est meilleur ? Je ne sais pas...
Il a fait des erreurs de toutes façons et il l'a reconnu sur son blog comme par exemple que Django supporte i18n out-of-the-box (contrairement à ce qui est dit dans sa présentation et il s'en excuse).
aussi, il dit que la documentation J2EE est très bonne avec plein de livres. En quantité, c'est tout à fait vrai, mais en qualité...
J'ai l'impression d'avoir fait des millions de tutoriels, officiels ou non, ces 3 derniers mois. Tous partent toujours du principe que tu connais déjà ce que le tutoriel est sensé t'apprendre et c'est ultra ennuyeux. Tu passes ton temps à essayer de deviner en lisant le code source d'exemples ci et là. Je sais que je vais paraitre encore un acharné de python, mais la doc python (et de la plupart des modules associés) est pour moi un vrai bonheur : tu suis pas à pas à partir du chapitre qui t'intéresse, bonne balance entre exemples et explications, etc..
Là où java est vraiment bon, à mes yeux, c'est la javadoc pour les API. Si tu sais ce que tu recherches, c'est le pieds. Mais encore faut-il le savoir.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: et sa conclusion ?
Posté par ccomb (site web personnel) . Évalué à 3.
[^] # Re: et sa conclusion ?
Posté par Gael Beaudoin (site web personnel) . Évalué à 6.
Je suis totalement d'accord avec la vidéo et les conclusions qui sont faites à propos de J2EE.
Cela dit, dans ce comparatif, il ne fallait pas inclure JBoss, mais Seam (qui fonctionne avec JBoss mais pas forcément lui) !
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 !
J'ai pas d'actions JBoss hein, c'est juste que je trouve la comparaison un peu injuste.
[^] # Re: et sa conclusion ?
Posté par near . Évalué à 2.
Cette solution est très interessante niveau robustesse (je trouve), sachant que j'ai aucune idée pour le python (pour comparer), je vais bientôt m'y mettre.
[^] # Re: et sa conclusion ?
Posté par Gael Beaudoin (site web personnel) . Évalué à 2.
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 ...
Ca dépend de tes besoins et de tes préférences.
[^] # Re: et sa conclusion ?
Posté par Nelis (site web personnel) . Évalué à 2.
# JBoss est compliqué
Posté par Pierre Tramonson . Évalué à 5.
En tous cas cela fait partie des critiques habituellement entendues envers JBoss.
Bon je ne l'ai jamais utilisé, je pense que je préférerais me tourner vers du JONas pour qqchose de plus simple.
# Seaside et squeak :-)
Posté par Miguel Moquillon (site web personnel) . Évalué à 10.
Mais, suis je bête, dans un tel monde, nous serions déjà dans des environnements virtuels 3D de type OpenCroquet qui reposerait sur un OS de type Plan9 et la construction de telles applications reposeraient sur le système collaboratif transparent de l'environnement qui lui même reposerait sur l'infrastructure distribuée transparente de l'OS ! Il s'agirait alors plus qu'à récupérer par drag&drop des objets par ci par là et de les assembler en décrivant leur relation (description syntaxique et sémantique), d'écrire de nouveaux objets graphiquement (aussitôt écrit, aussitôt instancié), puis d'exécuter le tout en modifiant à la volée le flot d'exécution pour corriger les éventuels bogues ou pour rajouter des évolutions sans remettre en cause l'exécution courante !
Bref, on a du chemin encore à faire ...
[^] # Re: Seaside et squeak :-)
Posté par Gart Algar . Évalué à 10.
[^] # Re: Seaside et squeak :-)
Posté par パパフラクス . Évalué à 2.
J'adore Smalltalk, et Seaside est effectivement très impressionant.
Par contre, et ce sont de vrai questions:
- Qu'est-ce que tu utilises pour la persistance (l'image c'est bof non ?)
- Une image, c'est pas évident pour le déploiement?
- Comment ça se passe le travail en équipe et la gestion de configuration avec Squeak.
- C'est quoi gemstone ?
Sinon, moi j'aimerai bien un framework web en Haskell.
Un autre truc qui me parait interessant, comme tu le souligne, c'est de pouvoir modifier les objets à la volée.
Un peu a la manière de pata pata http://patapata.sourceforge.net/
Pour ça, je suis persuadé que les langages à base de prototypes sont intéressants (par exemple Io http://www.iolanguage.com/ )
[^] # Re: Seaside et squeak :-)
Posté par mouftard . Évalué à 4.
Hmmm, y a rien d'aussi "sexy" que RoR/Django/... actuellement, mais on peut quand même noter l'existence de :
http://happs.org
http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH(...)
http://www.cs.chalmers.se/~d00nibro/hsp/
http://darcs.haskell.org/~lemmih/hasp/
C'est pas encore très organisé et je ne sais pas si ça correspond exactement à ta demande et tes besoins. Happs est celui qui a le plus le vent en poupe, récemment il a été utilisé pour écrire http://hpaste.org
[^] # Re: Seaside et squeak :-)
Posté par パパフラクス . Évalué à 1.
En fait j'ai pas de réel besoin dans ce domaine, c'est plus pour le fun ;)
Mais j'aime de plus en plus Haskell, je trouve que ça combine plutôt bien l'expressivité et le typage statique.
De plus comme je lisais récemment, les langages fonctionnels purs sont des bons candidats pour tirer partie des multi-coeurs/processeurs.
Mais on s'éloigne des framework web.
Effectivement RoR, Django et Turbogears sont sexy, personnellement, j'ai un peu peur de ce que certains dev pourraient écrire avec Ruby, et l'enfer de la maintenance qui pourrait en découler. J'ai une tendance naturelle vers la simplicité, et Ruby est tout sauf un langage simple, il n'y a qu'a regarder sa grammaire pour s'en convaincre.
[^] # Re: Seaside et squeak :-)
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
- L'image est au contraire idéale pour le déploiement car une image peut être chargée via le réseau à partir de ton environnement Smalltalk ou encore il suffit juste alors de saisir en ligne de commande par exemple : squeak monimage quelque soit la plate-forme.
- Dans squeak, toute la gestion de configuration et le travail en équipe est gérée de façon transparente. Pour gérer les différentes versions, en fait l'environnement sauvegarde chaque modification de ton image dans un fichier .changes qui contient toutes les modifications. Ce qui fait que si tu perd ton image, à partir de l'image d'origine, l'image finale peut-être reconstruite à partir de ce dernier fichier. Pour partager ton code et assurer de façon partagée la gestion de configuration, tu as ce que l'on appelle des serveurs squeaksource, équivalent aux sourceforge et l'outil Montecillo pour la gestion des révisions (+ d'autres outils). Tu as même des serveurs qui te permettent de travailler directement à partir de ton navigateur Web en utilisant le plugin squeak correspondant pour ce faire.
# Django
Posté par パパフラクス . Évalué à 4.
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.
[^] # Re: Django
Posté par PloufPlouf (site web personnel) . Évalué à 0.
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 www.djangoproject/documentation
le livre en cc ecrit par les auteurs de django
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 bon
en vous remerciant
[^] # Re: Django
Posté par NiCoS . Évalué à 2.
http://www.django-fr.org/
[^] # Re: Django
Posté par PloufPlouf (site web personnel) . Évalué à 1.
enfin voilà:
www.django-fr.org
le site des web gitans
en vous remerciant
[^] # Re: Django
Posté par CrEv (site web personnel) . Évalué à 3.
Pourquoi ? En quoi python serait plus lisible ?
Si je demande ça c'est que je fait le constat inverse... je trouve ruby bien plus agréable et facile à lire que python.
Il est vrai que ruby a quelques côtés un peu étrange, ou plutôt qu'on peut étendre très facilement le langage donc on peut se trouver dans des situations qui sortent des langages plus classiques, mais dans ce cas ce serait confondre lisibilité et méconnaissance.
Car dans un cas comme dans l'autre, il faudra tôt ou tard apprendre réellement le langage pour pouvoir l'utiliser et non plus simplement le lire.
Mais je trouve justement ruby suffisament verbeux et bien concu pour être facile à lire tout en restant relativement concis.
(ou alors c'est mon côté perl qui me fait trouver ruby tout à fait lisible...)
# Mes impressions
Posté par Damien Metzler . Évalué à 10.
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.
[^] # Re: Mes impressions
Posté par near . Évalué à 2.
[^] # Re: Mes impressions
Posté par Éric (site web personnel) . Évalué à 6.
On est franchement loin de Ror au niveau feeling, utilisation, installation/configuration ...
Ca fait de l'ajax, c'est mvc, il y a une interface en ligne de commande. Passer ces trucs super bateaux, le reste est franchement différent. Perso j'associerai beaucoup plus symfony aux frameworks java (config séparée du code, génération de la couche orm statique, peu de "magie" et beaucoup de cadre) qu'à Ror (totalement dynamique, peu ou pas de config, beaucoup de magie dans les comportements ...)
[^] # Re: Mes impressions
Posté par Damien Metzler . Évalué à 2.
En parlant de magie, Jboss/Seam en fait pas mal dans le monde J2EE. Je détaille pas encore parce que je débute, mais il y a des choses intéressantes.
[^] # Re: Mes impressions
Posté par ioguix . Évalué à 2.
C'est vrai.
Je ne suis plus d'accord là, à vrai dire je vais défendre un peu symfony.
Tout dépend de quel coté on se place, il y a un peu deux mondes qui s'affrontent à coup de troll : celui de ceux qui maitrisent leurs bases et ceux qui maitrisent le code. Un petit tour d'horizon totalement pas exhaustif :
- D'un coté, on parle de pérénité des données, contraintes sur les tables champs etc, maîtrise de la cohérence toussa et l'interface doit s'adapter à la base.
- De l'autre on peut parler d'environnements et applications rapides à developper, d'abstraction de la base, de la gestion des contraintes et cohérence des données depuis les couches applicatives, de non multiplication des languages, etc.
Moi, je cherche quelque chose de souple, permettant de jouer sur les deux tableaux et c'est là que je ne suis plus d'accord avec toi.
RoR t'impose bel un bien un cadre dont on peut trés peu s'affranchir : c'est la fameuse règle "convention plutôt que configuration". Si tu as déjà une base de donnée existante, cette règle devient plutôt handicapante...
Ce que j'ai trouvé de bien avec symphony (et les projets qu'il a fait naître autour), c'est justement qu'il te permet d'utiliser une base existante, qu'il va aller fouiner trés loins dans celle-ci pour en déterminer l'architecture et les contraintes et te produire une fameuse couche orm statique.
MAIS, cette couche orm statique, tu n'y touche pas. Les modifications et ajouts que tu apportes (et c'est l'esprit de tout le framework, pas seulement pour la couche orm) tu le fait dans des classes héritiaires qui elles sont conservées d'une génération de l'orm à l'autre.
Bref, Symphony pour moi, c'est beaucoup plus de souplesse, une maitrise du code et de la base.
Maintenant, il est bien connu qu'un framework dépassera rarement les 80/90% du travail avec toutes les outils qu'il t'apporte...C'est le reste qui te posera problème et prendra le plus de temps de travail...
mes 2¢ comme ils disent tous...
[^] # Re: Mes impressions
Posté par fredix . Évalué à 2.
Perso en Rails, mais ça doit être possible en PHP, je stocke mes objets en session. Par exemple j'ai un objet par page et je retrouve donc bien mon contexte.
[^] # Re: Mes impressions
Posté par Damien Metzler . Évalué à 1.
En J2EE l'objet (servlet, bean etc...) survit à la requête web autrement qu'en sérialisant ta session. Ta servlet est instanciée à la première utilisation, c'est un objet qui vit dans le conteneur (Tomcat, Jboss etc...). Un requête web attaque juste la méthode doGet ou doPost de cet objet. Si il y a beaucoup de requête, le conteneur peut décider d'instancier une nouvelle Servlet pour mieux gérer le bazarre, c'est pour ça qu'en terme de scalabilité c'est mieux en théorie (j'ai aucune idée sur la pratique).
[^] # Re: Mes impressions
Posté par fredix . Évalué à 1.
http://mongrel.rubyforge.org/
[^] # Re: Mes impressions
Posté par Moogle . Évalué à 1.
# Mon avis pro-Ruby on Rails
Posté par Nicolas Blanco (site web personnel) . Évalué à 1.
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.
[^] # Re: Mon avis pro-Ruby on Rails
Posté par ccomb (site web personnel) . Évalué à 2.
Une vue ne doit pas nécessairement être une page web, c'est censé être une vision particulière d'un contenu (par ex un objet). Donc ça peut générer une sortie PDF, une vue par FTP ou par WEBDAV ou en HTML, et dans ce cas une vue doit _utiliser_ un template, mais pas être un template. Il faut limiter au maximum le code contenu dans les templates, car c'est le boulot de la vue.
Dans zope3 une vue peut aussi être juste un morceau de page (un viewlet), qui est intégré dans un gestionnaire de viewlet et qui peut (ou non) utiliser un template pour son rendu. Ca permet de faire des pages avec des boites et des contenus complètement variables et dépendants du contexte, de manière très souple et très intéressante.
C'est vraiment regrettable que la doc et la visibilté de zope3 soient si faibles car les principes utilisés sont vraiments intéressants (on en retrouve dans j2ee, mais pas forcément de la même façon, et sans la soupless de python) et c'est un framework qui est maintenant très stable et très mûr.
[^] # Re: Mon avis pro-Ruby on Rails
Posté par Alex . Évalué à 1.
[^] # RESTfull + ActiveResource
Posté par Nicolas Blanco (site web personnel) . Évalué à 1.
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...
[^] # Re: RESTfull + ActiveResource
Posté par ccomb (site web personnel) . Évalué à 2.
A mon avis, le bon comparatif serait :
Rails / Django / Turbogears / Grok (qui arrive lentement)
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.
[^] # Re: RESTfull + ActiveResource
Posté par lolop (site web personnel) . Évalué à 2.
Parce qu'il me semble que certains de ces logiciels tournent aussi sous Windows.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: RESTfull + ActiveResource
Posté par ccomb (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.