Salut,
Je me renseigne actuellement sur les différents frameworks web qui me permettraient de développer un site web simplement et rapidement.
Afin de découvrir autre chose, je regarde vers d'autres langages que PHP.
D'après ce que j'ai pu voir il y à principalement 2 frameworks assez populaires, j'ai nommé Django et RoR. Il semblerait que RoR soit plutôt orienté application web tandis que Django soit orienté publication... Mais que désigne ces termes cela veut-il dire que Django ne peut pas faire ce dont est capable RoR ? J'en doute un peu...
Quoi qu'il en soit, j'ai aussi repéré Pylons, TurboGears ou encore Merb mais j'avoue ne pas savoir lequel prendre.
Je vais donc les essayer mais j'aimerais aussi avoir vos opinions. Lequel utilisez-vous et pourquoi ?
Je cherche à faire un petit site qui se chargera principalement de la gestion de fichiers audios, de l'écriture et de l'affichage de leurs tags avec quelques news.
Et regardant sur les exemples que l'on peut trouver le site de chaque framework, pour l'instant j'aime bien RoR qui me paraît assez clair dans son fonctionnement et dans la syntaxe Ruby.
Je ne connais pas Ruby mais sa syntaxe me plait et ça fait un petit moment que je n'ai pas touché à Python mais au moins je le connais un peu.
Alors, selon vous quel est le meilleur framework web ? ;-)
Journal Choisir un framework web...
22
jan.
2010
# Forum
Posté par Spack . Évalué à 1.
[^] # Re: Forum
Posté par vladislav askiparek . Évalué à 9.
[^] # Re: Forum
Posté par Spack . Évalué à 1.
[^] # Re: Forum
Posté par Maclag . Évalué à 6.
L'ergonomie du site a déjà été largement éprouvée dans une boulangerie!
---------------------> [ ]
[^] # Re: Forum
Posté par kikicnrv . Évalué à 3.
# Professionnel
Posté par icyfemur . Évalué à -5.
Je te conseille d'aller voir du coté des framework JEE, comme JSF, Struts, etc...
(Ben quoi, c'est vendredi non ?)
[^] # Re: Professionnel
Posté par icyfemur . Évalué à 8.
# Django
Posté par Ririsoft . Évalué à 10.
En utilisant Django non seulement tu apprendras des technologies web, mais tu apprendras aussi comment architecturer correctement une application.
Je passe sur le fait que c'est en Python et que ça ne te fera pas de mal de progresser dans le domaine tant ce langage est utilisé partout.
RoR te permettra de faire exactement la même chose que Django, aussi facilement. Mais Ruby ne prend pas tellement en dehors de RoR et des appli web : investir là-dedans est bien moins intéressant (sur le plan rendement de ton temps libre ou professionnel) que dans Python, sauf si c'est pour satisfaire ta curiosité et t'amuser un peu.
Faire l'impasse sur Django serait vraiment dommage. Au moins lis la documentation en ligne des principes généraux du framework avec les modèles de données et de vues !
Tu trouveras des sites d'hébergement gratuit de tes applications Django (chez Google entre autres).
Amuses toi bien !
[^] # Re: Django
Posté par steckdenis (site web personnel) . Évalué à 2.
De plus, ce site web est disponible sous GPLv3 (Affero GPLv3 à partir de ce week-end, donc faut se dépêcher pour faire des magouilles avec :P ), et je reste disponible pour de l'aide (mais faut avoir bien cherché avant de me demander, je suis très occupé. steckdenis chez logram tiret project point org).
La documentation officielle est très bien développée, le site django-snippets est excellent, on trouve une belle blogosphère autour, et c'est rapide, très rapide (j'ai eu l'occasion de tester RoR, c'est horrible ce machin, à peu près 3s pour générer une page toutes les ~100 pages, même si c'est 0,1 seconde par page ensuite).
Sur mon Kimusufi 2XL (Un P4 mono-core hyper threading 3,2Ghz, 2Gio de RAM), avec le serveur web Nginx (que je conseille : configuré en 20 minutes en comptant la lecture de la doc, ça marche, c'est simple, puissant et rapide), je peux obtenir facilement 40 pages par seconde aux endroits complexes, une petite centaine sur les pages simples avec des templates simples. Nginx sur les fichiers statiques monte facilement à 16 000 pages par seconde !
Bref, Django est la voie, et en une semaine, on maîtrise le bazar (expérience perso, et en plus, j'ai appris le Python en même temps que Django, comme quoi les deux sont simples et puissants).
[^] # Re: Django
Posté par totof2000 . Évalué à -4.
Je ne suis pas sur que Python puisse permettre de faire tout ce que fait Ruby. Sinon, il est vrai que c'est dommage que ce langage ne prenne pas tant que ça : il n'a rien à envier à Python (et Python non plus n'a rien à lui envier : ce sont deux approches différentes).
[^] # Re: Django
Posté par manatlan (site web personnel) . Évalué à 8.
> de faire tout ce que fait Ruby
C'est vendredi (enfin là, plutôt samedi), mais faut pas exagérer non plus ;-)
tu peux préciser ta pensée ?
[^] # Python vs Ruby
Posté par Arthur Accroc . Évalué à 3.
Tu veux dire que c’est quand même malheureux que Python n’oblige pas comme Ruby à faire des contournements foireux pour palier l’absence de destructeurs ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Python vs Ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Ce que j'aime bien dans Ruby que je n'ai pas retrouvé en Python, c'est la cohérence. Il y a très peu de principes à savoir en Ruby, et lorsqu'on les a saisis, on devine facilement comment va se comporter le langage dans un cas inconnu.
Un exemple pour étayer mon propos : self n'est pas défini lors de la définition de la classe en Python. On a aucun moyen d'accéder à l'objet qu'on est en train de définir.
[^] # Re: Python vs Ruby
Posté par zebra3 . Évalué à 2.
C'est quoi l'intérêt d'accéder à quelque chose qu'on est en train de définir et qui n'existe donc pas encore ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Python vs Ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Ensuite, à partir du moment où tu commences à définir ta classe, elle existe, tout comme le fait qu'un objet existe avant que le constructeur soit terminé. Parce que étant donné qu'on peut rajouter des méthodes à la volée, même si c'est plus galère et/ou moche en Python qu'en Ruby, ta classe n'est jamais complètement définie (au sens ou les méthodes des objets de la classe ne sont jamais figés).
Par exemple, en Ruby, si tu fais
def monobjet.manouvellemethode
…
end
tu crées une méthode qui n'existera que sur l'objet monobjet, et pas sur tous les objets de la même classe. Pour créer une méthode de classe, tu utilises exactement le même concept : tu crées une méthode sur la classe que tu es en train de définir.
De même, créer une classe anonyme se fait simplement en instanciant un objet de type class. Quoi de plus logique ?
[^] # Re: Python vs Ruby
Posté par Octabrain . Évalué à 3.
# contexte de test
class C: pass
o = C()
# ajout
makemethod = lambda obj, func: lambda *a, **k: func(obj, *a, **k)
o.test = makemethod(o, lambda self, arg: 'self=%s, arg=%s' % (self, arg))
# test
o.test(42)
=> 'self=<__main__.C instance at 0xa1be8ac>, arg=42'
Tu vas me dire que c'est compliqué, je te répondrai que ça ne sert quasiment jamais, alors ce n'est vraiment pas compliqué en comparaison de ce que tu essayes de faire.
Classe anonyme en Python : type("", (), {})
[^] # Re: Python vs Ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
[^] # Re: Python vs Ruby
Posté par Octabrain . Évalué à 4.
Rajouter une méthode à un objet uniquement, pour moi, cela va carrément à l'encontre des principes de l'orienté objet. Du coup, c'est juste un bricolage, un hack laid pour faire quelque chose qu'on a la possibilité technique de faire, même si c'est moche et ça renie la conception objet. La possibilité de le faire est presque un détail d'implémentation dont on abuse.
[^] # Re: Python vs Ruby
Posté par jhc_ . Évalué à 2.
Dans du code propre, on inclut des méthodes dans un module, et on crée une méthode qui vient encapsuler l'inclusion de ce module.
On se retrouve donc avec un ensemble de méthode qui véhiculent un concept donné, que l'on applique à un objet. Cela se retrouve dans Rails avec tous les act_as_tree, has_attached_file et autres, qui viennent tout encapsuler.
Moralité, d'un point de vue du développeur qui utilise une telle librairie, la seule chose que j'ai à connaître c'est c'est la méthode pour intégrer les fonctionnalités et son prototype. La personne qui développe l'API peut ainsi modifier autant qu'elle le souhaite son code, faire absolument tout ce qu'elle veut tant qu'elle respecte le *contrat* passé avec le développeur, c'est à dire la méthode d'inclusion. Finalement c'est indépendant de toute forme d'implémentation, donc beaucoup plus encapsulé.
Je vois mal comment je pourrais arriver à une telle souplesse avec de l'héritage, avec un *contrat* si simple avec le programmeur. Cela ne me parait pas du tout être en contradiction avec le paradigme de la POO, c'est juste une différence fondamentale entre les langages dynamiques et statiques. Enfin, je comprend tout à fait ta résistance face à ce concept, je travaillais exclusivement en C++ il y a quelques années et ces concepts me faisait hérisser les poils. Et puis j'ai testé, la clarté du code qui en résulte m'a surpris au plus haut point. L'écriture de DSL d'ailleurs serait impossible sans une telle possibilité.
La notion de rajouter une méthode à un objet à la volée est à prendre aussi avec des pincettes dans le sens où généralement il est peu courant de le faire hors de la phase de création d'une instance. Parcourir les différentes implémentations des design patterns en Ruby est surprenant de synthétisme et lisibilité ( une fois les concepts de base maitrisés ).
[^] # Re: Python vs Ruby
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Pas pour moi, sauf si tu considères
1/ que smalltalk n'est pas un bon représentant de la POO
2/ qu'un logiciel critique ne peut être écrit en POO (car tu t'opposes à la mise-à-jour dynamique de code [1])
[1] : http://portal.acm.org/citation.cfm?id=1542478 Et c'est pas un hack, t'as même un formalisme mathématique derrière…
[^] # Re: Python vs Ruby
Posté par Octabrain . Évalué à 2.
Tu parles de @classmethod ?
[^] # Re: Python vs Ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
C'est donc nettement moins souple qu'une méthode qui prend en paramètre une classe. Par exemple, je veux créer une méthode qui prenne en paramètre une classe et une chaîne de caractère, et crée plusieurs méthodes dans la classe, dont le code est basé sur la chaîne.
D'autre part, si un décorateur n'est rien d'autre qu'un appel de méthode, pourquoi n'est-ce pas la syntaxe d'un appel de méthode. Pour moi, et c'est très subjectif bien sûr, je trouve ça incohérent. Ça me gonfle d'avoir à apprendre quinze concepts et syntaxes pour faire des choses qui sont intrinsèquement la même notion.
[^] # Re: Python vs Ruby
Posté par Octabrain . Évalué à 2.
Par ailleurs, tu peux très bien écrire
def func
...
func = deco(func)
plutôt que
@deco
def func
...
[^] # Re: Python vs Ruby
Posté par jhc_ . Évalué à 2.
[^] # Re: Python vs Ruby
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Récursion, induction, co-induction…
T'as plein de concepts sympatoches (et réellement pratiques) qui reposent sur cette possibilité.
[^] # Re: Python vs Ruby
Posté par Antoine (site web personnel) . Évalué à 2.
[1] Genre :
class Truc:{ici}
[^] # Re: Python vs Ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Quand je crées une nouvelle classe, je ne fais qu'instancier un objet de type Class. Lorsque je la définis, je suis dans le constructeur de cet objet, et donc self est bien défini, et représente l'instance que je suis en train de définir.
Je ne trouve pas ceci cohérent avec le principe « tout est objet » :
stripatublu% python
Python 2.5.4 (r254:67916, Nov 19 2009, 22:14:20)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Plop:
... pass
...
>>> Plop().__class__
<class __main__.Plop at 0x7f82a55b36b0>
>>> Plop.__class__
Traceback (most recent call last):
File "", line 1, in
AttributeError: class Plop has no attribute '__class__'
En ruby, une classe est objet, tu peux créer une classe en appelant le constructeur de Class, et dont le scope n'est pas global. Ça, c'est cohérent avec le principe « tout est objet ».
[^] # Re: Python vs Ruby
Posté par Pierre Palatin (site web personnel) . Évalué à 2.
In [12]: class Plop(object):
....: pass
....:
In [13]: Plop().__class__
Out[13]: <class '__main__.Plop'>
In [14]: Plop.__class__
Out[14]: <type 'type'>
Toute (nouvelle) classe est sensée être déclarée comme hériter de 'object' (new style class). Une classe est donc également un objet.
Devoir 'object' manuellement est effectivement p-e pas très joli, mais cela a été fait pour garder la compatibilité avec les versions précédentes de python. Amha, le gain "garder compatibilité avec une legere surcharge syntaxique" est nettement plus intéressant que "avoir les classes comme des objets" qui en pratique est certe joli mais moins souvent utile que une bonne compatibilité ascendante.
Python 3k corrige cela, hériter de 'object' n'est plus nécessaire.
[^] # Re: Python vs Ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
[^] # Re: Python vs Ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 7.
stripatublu% python
Python 2.5.4 (r254:67916, Nov 19 2009, 22:14:20)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Plop:
... def __plop(self):
... pass
... def __plop__(self):
... pass
...
>>> plop = Plop()
>>> plop.__plop()
Traceback (most recent call last):
File "", line 1, in
AttributeError: Plop instance has no attribute '__plop'
>>> plop.__plop__()
>>>
Les plus trolleurs auront remarqué le message d'erreur très explicite.
[^] # Re: Python vs Ruby
Posté par Octabrain . Évalué à -1.
T'as tellement peu d'arguments que tu en es réduit à donner tant d'importance à un tel détail ? On se demande bien qui trolle...
[^] # Re: Python vs Ruby
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
[^] # Re: Python vs Ruby
Posté par Octabrain . Évalué à -3.
[^] # Re: Python vs Ruby
Posté par Alex . Évalué à 2.
Faut arrêter de toujours vouloir croire que ce qu'on défend est parfait (que ca soit ruby ou python ou autre)
[^] # Re: Python vs Ruby
Posté par Octabrain . Évalué à -2.
[^] # Re: Django
Posté par Mildred (site web personnel) . Évalué à 2.
Je crois qu'il y a quelque chose que Ruby peut faire de base, mais que python ne peux pas (sauf avec PyPy ou d'autres, mais qui ne sont pas encore matures) c'est l'exécution d'un script d'origine non authentifiée dans un environnement restreint.
Et je trouve que c'est important quand même. Ça permet entre autre de pouvoir utiliser des scripts python sur le web (comme JavaScript) ou pour d'autres usages similaires.
[^] # Re: Django
Posté par monde_de_merde . Évalué à 2.
Ça permet par exemple de sélectionner les module qui pourront être importés, les fonctions built-in qui pourront être utilisée etc...
[^] # Re: Django
Posté par Octabrain . Évalué à 2.
[^] # Re: Django
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
http://en.literateprograms.org/Turing_machine_simulator_(Rub(...)
http://dir.filewatcher.com/d/Other/src/Development/Languages(...)
Ben si, ils savent tous les deux faire ce que l'autre sait faire…
[^] # Re: Django
Posté par GeneralZod . Évalué à 10.
Django est un excellent framework web en Python mais ce n'est certainement pas LE framework python.
Django souffre gravement du syndrome NIH, Django n'exploite pas toutes les finesses du langage (genre les décorateurs abondamment utilisés dans CherryPy ou TG), la spécification WSGI est quasi inconnue de Django. Django est certainement un des favoris pour le titre de "LE framework web", mais probablement pas dans la catégorie "LE framework web en Python".
Pylons et TG sont également de très bons frameworks MVC, bien documenté, réutilisant des composants existants (moteur de templates: genshi, mako, etc .., ORM: SQLAlchemy, Storm etc...), respectant la spécifications WSGI (possibilité de réutiliser les middlewares existants comme le module d'authentification de Zope Cf projet Repoze).
Tout ces frameworks sont très bien, Django semblera plus naturel à un développeur web avec une expérience antérieure des frameworks PHP, Pylons/TG parleront plus à un développeur Python chevronné.
Mais il y a également d'autres frameworks très bien comme le minimaliste Werkzeug.
[^] # Re: Django
Posté par matli . Évalué à 5.
[^] # Re: Django
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
trait d'union - supérieur - crochet ouvrant - crochet fermant
[^] # Re: Django
Posté par Ontologia (site web personnel) . Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Django
Posté par vladislav askiparek . Évalué à 2.
[^] # Re: Django
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
L'autre gros avantage de Django sur RoR, c'est que c'est très facile à installer et configurer sur un serveur de prod.
Sur un serveur Debian, tu installes le paquet python-django, tu rajoutes quelques lignes à ta config apache pour créer un VirtualHost django (voir la doc) et c'est tout.
Avec RoR, je n'ai jamais eu que des galères pour l'installer et les packageurs Debian s'en plaignent car c'est impaquetable, inmaintenable, …
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Django
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Si tu parles de http://pkg-ruby-extras.alioth.debian.org/rubygems.html, c'est quand même pas auusi noir que tu le laisses entendre...
Surtout que depuis que passenger existe (et il est dans Debian), déployé une appli rails est devenu un jeu d'enfant.
[^] # Re: Django
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mais malgré tout, c'est de nouveau un truc en plus à apprendre dont je n'ai rien à faire. Gems ? Passenger ? Je ne veux pas savoir ce que c'est, je veux faire soit apt-get install (pour les librairies), soit placer du code en user space (pour les développements maison). Je veux que mon code 3rd party soit automatiquement à jour au niveau sécurité, je ne veux pas de traitement de faveur ni me prendre la tête.
Ce que Django permet de faire très facilement et très proprement. J'en suis très heureux.
Note que, bien qu'étant un inconditionnel de Python, j'adresse également la même critique aux eggs de Python, qui sont à mes yeux une horreur tout comme les gems.
Je rajoute un autre bénéfice de Django : tu peux utiliser toutes les libs Python (xmpp, reportlab,…) bref, c'est le bonheur.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Django
Posté par jhc_ . Évalué à 2.
( quoi que je ne trouve pas que ./script/server soit particulièrement compliqué dans ce contexte )
Par contre, je ne saisis pas ta dernière remarque, tu peux tout à fait utiliser toutes les gems que tu souhaites depuis ton application RoR, à vrai dire, il n'y a quasiment plus de plugins aujourd'hui, tout est livré sous forme de gems (librairies) donc.
[^] # Re: Django
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Pourquoi "mettre en prod" devrait-il être synonyme de "se prendre la tête" ?
Mon raisonnement est tout simple :
Est-il possible de maintenir un serveur Django (sécurité, mises-à-jour) sans rien connaître de Django ou même Python ?
Oui, tout à fait. Il suffit d'installer les bons paquets avec apt-get. Seule contrainte : une config apache particulière pour les VirtualHosts django. Une fois que t'as cette config, tu n'as même pas besoin de savoir que django tourne : tout est géré avec apt-get upgrade.
Point barre.
Essaye de me faire la même chose avec RoR. Impossible (du moins lors de mes essais).
Je ne veux pas des gems, des eggs ou des brols de ce genre. Je veux apt-get.
D'ailleurs, ça a toujours été le gros reproche que j'ai entendu à propos de RoR : c'est génial pour les développeurs mais un cauchemar pour les administrateurs.
RoR a le grand mérite d'avoir ouvert une voie, d'avoir popularisé une nouvelle approche. Mais, d'un point de vue purement pragmatique, il me semble que pour un nouveau qui débarque, se mettre à un framework Python ou Php me semble beaucoup plus logique et plus rentable.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Django
Posté par jhc_ . Évalué à 2.
Concernant les gems / paquets debian c'est clairement une horreur dans l'état actuel des choses. Le problème c'est que Ruby de manière générale voit son écosystème évoluer très très rapidement. Peu d'acteurs majeurs se posent la question du : est-ce que c'est bien packagé ? pour développer, c'est d'ailleurs ce qui permet à ce petit monde d'avancer aussi vite et de voir des librairies se voir régulièrement remplacée par des versions plus évoluées, plus pratiques ou plus claire.
Clairement, c'est un problème à gérer coté déploiement.
Personellement, après m'être arraché les cheveux, j'ai décidé de fournir mes applications directement avec toutes les dépendances bundlés dans l'appli ( non je ne suis pas un sale qui a tout cela sur son repository, juste dans mon script de déploiement je freeze tout ), ainsi c'est moi qui prend en charge cette partie, vu que moi, développeur j'y comprends quelque chose ( à tout ce bazar ^^). Oui, c'est moins élégant, mais cela fonctionne diablement mieux en pratique ( et le sysadmin peut reposer ses cachets de Xanax ). A administrer c'est update de passenger, ruby éventuellement et ... c'est tout (avec apt-get hein). Le pire c'est qu'une telle solution, c'est une seule commande pour le développeur.
Ror était un tel cauchemar avant Passenger, je t'invite à lire juste un howto Debian pour constater à quel point cela peut être simple aujourd'hui.
Enfin ma réponse à ta dernière opinion peut être considéré comme du troll, mais il me semble que le point innovant à proprement parler est Ruby et sa philosophie, pas juste un framework ou deux. Je n'ai pas les moyens de l'expliquer de manière concise, aussi je ne m'aventurerais pas à le faire, juste je pointe dans une direction si cela t'intéresse d'approfondir ta réflexion.
[^] # Re: Django
Posté par CrEv (site web personnel) . Évalué à 2.
lapincompris
tu compares quoi ?
les egg et les gems ?
un egg n'est pas un paquet debian, si ?
Tu sais, certaines distrib package des lib ruby hein... si c'est pas bon chez toi faut ptetre regarder ailleurs.
> Essaye de me faire la même chose avec RoR. Impossible (du moins lors de mes essais).
ben je sais pas, genre :
# aptitude install apache rails mongrel# viemacs /etc/apache2/sites-available/monsite# /etc/init.d/apache restartCa ne convient pas ?
[^] # Re: Django
Posté par jhc_ . Évalué à 1.
Personnellement sur *mes* debians je mets Ruby EE et je m'abstrais du système de paquetage.
Sur celle de mes clients, je freeze tout dans l'appli comme je l'ai décris au dessus, et je reste sur le ruby du système.
Par contre oui, la procédure que tu décris est très simple, et peu semble en avoir entendu parler ...
[^] # Re: Django
Posté par Ontologia (site web personnel) . Évalué à 1.
# viemacs /etc/apache2/sites-available/monsiteQuoi ????!!
Tu n'utilises pas Vim ???!!!
Ok, je -----> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Django
Posté par CrEv (site web personnel) . Évalué à 2.
(véridique en plus, c'est mon oséditeur de texte principal au boulot)
# pour ma part j'ai choisi ROR et je le conseille ...
Posté par totof2000 . Évalué à 1.
- il faut suffisamment connaître Ruby et ses "astuces" pour pouvoir apprécier Rails. Je suis passé à rails en ne connaissant pas Ruby et certaines choses me sont passés par dessus. Ruby est assez facile à apprendre (surtout si tu connais Python).
- si tu achètes un bouquin, assure-toi que la version de Rails que tu installe est bien celle qui est utilisée par l'auteur du bouquin. Pour ma part je me suis fait avoir: j'ai installé un Rails 2 alords que mon bouquin causait en Rails 1.8 (de mémoire). J'ai perdu du temps sur des différences subtiles.
- chaque mot d'une doc Ruby est important, bien pesé; Il ne faut pas survoler la doc ou un bouquin mais bien la lire. Pour ma part, j'ai parfois tendance à survoler certaines parties d'une doc lorsque je cherche des infos pour ne me concentrer que sur le point qui m'intéresse. Avec Rails ça a été une erreur. Pourquoi ? Parce que Rails adopte le principe "convention plutot que configuration", et en lisant rapidement je suis passé à coté de certaines de ces convention, notamment lorsque j'ai voulu aborder les relations de plusieurs à plusieurs (les tables permettant d'effectuer la relation doivent être créées de façon précise : le nom des deux tables à joindre, mais par ordre alphabétique. Je n'avais pas prêté attention à l'ordre de création, me concentrant sur le reste et j'ai passé deux jours à chercher pourquoi ça ne marchait pas). Par contre quand tu te fais avoir une fois, après tu n'oublies plus.
Si tu as fait du Python, tu apprendras vite Ruby. Il faudra juste changer un peu certaines habitudes. Pour ma part j'ai trouvé que Ruby était une libération par rapport à Python, sans être non plus un truc trop permissif comme Perl.
Un bouquin que je te conseille : les design pattern en Ruby ( http://designpatternsinruby.com/section01/ab_reviews.html - il en existe une traduction française ). Tres bon bouquin pour qui veut se mettre à Ruby et/ou à Rails. Il ne parle pas expressement de Rails mais permet de comprendre ce quise passe sous le capot de Rails.
Pour Rails en lui même je ne sais pas trop quel bouquin conseiller.
# Merb et Rails
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Je te déconseille de partir sur Merb. C'est un très bon framework, mais peu documenté, et surtout, qui ne va plus évoluer. Les équipes de Ruby on Rails et de Merb ont décidé il y a un an d'unir leurs efforts pour fournir une nouvelle version majeure de Rails qui fournirait le meilleur de Rails et le meilleur de Merb.
Depuis, Merb et la branche stable de Rails (Rails 2.3) ont très peu bougé, les développements se sont concentrés sur Rails 3, dont une version beta devrait sortir d'ici peu (première quinzaine de février dit ma boule de cristal).
Comme très peu de personnes ont essayés Rails 3 pour le moment, il est encore assez difficile de savoir si Rails 3 sera une grand réussite ou un flop. Les premiers articles que l'on commence à voir sont très enthousiastes et montrent que l'API de Rails a profondément évolué entre Rails 2.3 et Rails 3. Il faudra donc sûrement réapprendre pas mal de choses pour suivre ce changement, et il serait donc dommage d'acheter maintenant un livre sur Rails. Par contre, ça me semble être une bonne période pour apprendre Ruby ;-)
# Turbogears et grails
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 3.
Ils sont finalement très proche en philosophie, ils permettent de construire rapidement une appli puissante et sur mesure.
- l'architecture MVC est bien concu avec tout ce qu'il faut (moteur de templation, ORM, ...)
- On défini exactement le modèle (objet et relationnel) de chacun de ses objets metiers et les relations entre elles, et on dispose d'un ORM performant.
- Ils disposent de nombreux plugins pour ne pas reinventer la roue à chaque fois
- Ils sont documentés
- Ils sont tres productif, le langage est peu verbeux, ça va vite, le code est élégant avec peu de (mauvaises) surprises
- Les deux embarquent un serveur web et une base de donnée, pour aider en phase de dev
Ensuite, + spécifiquement:
- Turbogears pose quelques soucis: Depuis la sortie de TG 2.0, pleins de docs, y compris l'officiel, ne sont plus a jours, les tutoriaux non plus. Y'a souvent besoin d'aller voir le code source de TG pour s'en sortir, les plugins dispo sont souvent pas fini ou au stade "proof on concept" et faut parfois bidouiller un peu... Y'a un domageable coté "couscous" dans tout ce qui tourne autour du truc.
Maintenant, y'a toujours moyen de s'en sortir (surtout qu'on avait un pro de TG dans l'équipe), on a pas rencontré de limitations par le framework lui meme qui est franchement bien conçu (a commencer par les décorateurs par exemple).
- Grails a pour lui une base de plugins de grande qualité, installable aussi facilement qu'un plugin firefox, une doc et des tutoriaux à jour, ... L'archi me semble ultra saine, l'ORM est performant, ....
L'avantage pour moi est quand meme qu'il s'agit de J2EE, on a acces à l'immense bibliotheque existante, l'acceptation dans le milieu professionnel (là ou Python aura plus de mal a passer), l'integration dans des ensemble plus grand.... Bref, une grande ouverture d'utilisation.
L'avantage du Java/J2EE... mais sans les inconvenient. C'est rapide, pas verbeux, et pas de soucis d'architecture ou de prise de tete concernant les design patern... vue qu'elle est déjà faite ;) De quoi se réconcilier, à titre perso, avec le J2EE. Voir d'en tomber amoureux.
Le seul truc, pour etre fair play, c'est que je n'ai pas poussé autant dans les retranchement Grails que Turbogears, notamment ce qui serait l'équivalent des décorateurs.
Bon, coté plugin de grails, je ne peux pas ne pas citer:
http://www.grails.org/plugin/class-diagram
qui genere un diagramme UML de ta réalisation, forcement à jour donc ;)
[^] # Re: Turbogears ...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
- utilisation de notre technologie disponible sous forme de bibliothèques dynamiques,
- utilisation d'un ORM pour s'affranchir (autant que faire se peut) de la couche SQL,
- services web en SOAP,
- application web d'administration,
- Réutilisation maximale du code entre les différentes applications (on a développé un SI qui tourne avec une trentaine de machines, gérant chacune des services spécifiques).
PHP, on l'a mis de côté, notamment parce l'utilisation de bibliothèques dynamiques nécessite de coder des plugins (pas en langage interprété).
Finalement on utilise :
- TG2 pour la partie application web. L'intérêt c'est notamment qu'il utilise des modules indépendants comme SQLAlchemy pour la partie ORM qui est super bien fait (hormis des "problèmes" de cache pas toujours évident)
- CherryPy / Soaplib pour les services SOAP (et suds pour la partie clients SOAP)
Ca permet notamment de réutiliser SQLAlchemy sur tous les logiciels qu'on a du développer, que ce soit pour les démons de backoffice, les services SOAP, les applications web.
Si tu te limites au "web", je ne sais pas si python est le plus adapté, si tu fais un peu de tout, clairement c'est une force. Notamment pour ses capacités d'introspection.
Un exemple : on a une classe qui centralise tous les codes d'erreur et les messages associés. Elle est utilisée "classiquement" par l'ensemble du code ; l'introspection permet également de générer à la volée une page web qui liste tous les codes d'erreur. Tout ça en ayant "codé en dur" les messages et codes d'erreur (j'aime pas le principe qu'un code d'erreur soit "paramétré dans un fichier : tu peux pas assurer qu'il ne sera pas modifié "involontairement" ou tout simplement "à jour...)
Les seuls points noirs avec python c'est à mon avis :
- qu'il n'est pas typé (ta variable peut être du texte, un objet, etc sans que tu puisses garantir qu'il restera toujours du même type
- Qu'il n'y a aucun moyen de savoir si ton code est valide à moins de faire des tests de tous les cas de figure. Exemple : un log mal formatté qui est affiché dans les cas vraiment exceptionnels ne sera pas détecté squf lorsque ce cas exceptionnel intervient (ie en prod dans un cas de figure improbable et ça te génère une exception qui peut potentiellement faire planter tes services).
Mais pour revenir au sujet original, TG2 est vraiment agréable à utiliser et super flexible.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Turbogears ...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
- Pylons pour la partie web,
- SQLAlchemy pour la partie "abstraction de base de données"
- Genshi pour les templates HTML
- ToscaWidgets pour la génération / validation de formulaires
- repoze pour l'authentification
Tout ceci est "par défaut" ; il est tout à fait possible de changer les technologies sous-jacentes en fonction de tes besoins / connaissances.
Personnellement, je vois TurboGears comme un "packaging" de différentes technologies qui sont au top dans leur domaine. Ca rejoint un peu la philosophie Unix : une agglomération d'outils qui font une seule chose mais qui la font bien.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Turbogears ...
Posté par paco81 . Évalué à 2.
Les seuls points noirs avec python c'est à mon avis :
- qu'il n'est pas typé (ta variable peut être du texte, un objet, etc sans que tu puisses garantir qu'il restera toujours du même type
- Qu'il n'y a aucun moyen de savoir si ton code est valide à moins de faire des tests de tous les cas de figure. Exemple : un log mal formatté qui est affiché dans les cas vraiment exceptionnels ne sera pas détecté squf lorsque ce cas exceptionnel intervient (ie en prod dans un cas de figure improbable et ça te génère une exception qui peut potentiellement faire planter tes services).
Certes ce n'est pas intégré au langage, mais il y a quand même des outils pour ça : le module typecheck pour forcer les types, pychecker pour la vérification du code, et certainement d'autres encore.
Après, je sais qu'ils existent, mais je ne les ai jamais utilisés... parce que je n'en ai jamais senti le besoin !
# Wicket
Posté par thedude . Évalué à 2.
Bon, j2ee tout ca, si t'as des besoins simples, ca va probablement prendre une enclume pour ecraser une mouche, mais sait on jamais.
Personnelement, le html me donne des boutons, donc plus je m'en eloigne, plus je suis content, donc j'ai pas d'avis a en donner, mais on l'utilise sur l'autre projet de la boite, les devs en sont tres content, ca rend bien et ca a l'air bien gaule.
Une bonne archi coherente et tout, une bonne doc, bref, apparement ca marche bien.
[^] # Re: Wicket
Posté par Antoine Mercadal (site web personnel) . Évalué à 1.
[^] # Re: Wicket
Posté par thedude . Évalué à 3.
Bon, j2ee tout ca, si t'as des besoins simples, ca va probablement prendre une enclume pour ecraser une mouche, mais sait on jamais.
j2ee c'est fait pour rendre des trucs tres compliques faisables et maintenables.
Apres si certains architectes ont tendance a abuser de la coc' et des design pattern pour faire des factory de factory et finissent avec plus d'interfaces que de concrete classes, c'est pas trop la faute du langage/framework, plutot des architectes en question.
J'en ai vu des merdes de ce genre, une particulierement rigolote de chez ft r&d qui consistait a reimplementer les pipelines cocoon dans une instance de cocoon (qui ne definissait evidement qu'un seul pipeline avec une seule action), et qui avait entre autres perles un genre factory, mais pas vraiment, avec un switch case de 700 lignes.
Les attrocites, ca s'ecrit dans n'importe quel langage.
Etonnament, c'etait un des projets avec le plus gros turnover de la ssii, il servait beaucoup a boucher les intercontrats. Et apres on s'etonne que l'appli soit un monstre a 6 tetes.
J'ai aussi vu des trucs tres bien ecrit, tres clair, sans design pattern a la con juste pour le principe de cocher la case "design pattern".
La principale difference avec php/python/ruby et autre, c'est que la nature non typee/non compilee de ces langages fera que ton projet petera de partout avant que t'aies pu finir ton usine a gaz...
[^] # Re: Wicket
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Je nuance :
1) Un programmeur J2EE, c'est fait pour transformer un problème simple en un "truc" très compliqué.
2) J2EE c'est fait pour faire croire à un chef de projet que le truc très compliqué est faisable.
Bonus :
3) J2EE permet de créer de l'emploi en permettant à autant de personnes que le budget le permet de travailler non-stop et d'être productif sans que le projet initial n'avance d'un iota.
https://linuxfr.org//~ploum/27723.html
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Wicket
Posté par hvannentir . Évalué à 1.
> "La principale difference avec php/python/ruby et autre, c'est que la nature non typee/non compilee de ces langages fera que ton projet petera de partout avant que t'aies pu finir ton usine a gaz..."
C'est quand même le vieil opinion sans argument juste pour essayer de clôturer un débat qu'on sent perdu d'avance.
Dans le même genre je peux en faire aussi : Non J2EE n'est pas une solution web correcte. Quoique qu'on fasse, pour rendre l'application performante avec une bonne montée en charge, il faudra le double d'investissement en exploitation qu'un projet en PHP,Python, Perl et autre.
[^] # Re: Wicket
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Wicket
Posté par hvannentir . Évalué à 2.
Le tiens n'avait pas besoin d'être libellé comme tel pour clairement apparaître comme un bon gros troll :)
# pourquoi pas en php ?
Posté par emabc . Évalué à -2.
[^] # Re: pourquoi pas en php ?
Posté par manatlan (site web personnel) . Évalué à 4.
c'est dit dans le texte
# Pour apporter ma pierre
Posté par manatlan (site web personnel) . Évalué à 1.
Cependant, regarder du côté du pure WSGI peut être interessant. Je suis un adepte du http://pythonpaste.org/do-it-yourself-framework.html , et de la réutilisation ;-)
Il y a toutes les briques en WSGI, pour faire exactement ce que tu veux.
Pour le R/W de tag id3/ogg/ape, mutagen sera parfait
http://code.google.com/p/quodlibet/wiki/Development/Mutagen
# Play
Posté par lezardbreton . Évalué à 3.
# SPIP ;o)
Posté par bob le homard . Évalué à 2.
On fait tout et n'importe quoi avec du SPIP. il possède son propre langage de programmation même si c'est du php derrière.
Je m'en sers pour faire à peu près tout ce dont j'ai besoin :
- site de chat (ajax)
- sites institutionnels multilingues
- base de données en ligne
- blogs (allant jusqu'à prendre en charge les mêmes thèmes que dotclear)
- génération de flux xml pour applis smartphone
etc...
Et puis c'est libre et il y a une forte communauté derrière.
;o)
[^] # Re: SPIP ;o)
Posté par LeJulien . Évalué à 0.
<BOUCLEma_vie(BREVES_DE_COMPTOIR){id_de_pourquoi_tu_lui_parle_de_spip_toi?}>
Après ça va dépendre de ses besoins. Apprendre le langage de boucles, parcourir la doc de l'api pour coder en 45 minutes ce que tu fais en 10 avec RoR ce n’est pas forcement intéressant.
Parce que bon, fondamentalement Spip est un bon CMS, l'utiliser comme un framework est souvent une perte de temps. Après, Spip dispose de tellement de fonctionnalités et plugins qu'il est très rare de devoir l'utiliser comme un framework/ et ou utiliser un véritable framework.
</BOUCLEma_vie>
# moi j'aurai tendance...
Posté par Axel R. (site web personnel) . Évalué à 5.
C'est un site où tu auras beaucoup de données à gérer ? quel traffic tu comptes avoir ?
Il y a plusieurs critères à prendre en compte, les langages que tu maitrises (effectivement, ça sera plus simple de faire du TurboGears ou du Pylons), l'aide que tu peux avoir de la part de la communauté (les forums autours de RoR sont plus nombreux qu'autours de Merb), ce que tu connais déjà (si tu connais bien le PHP, il existe le PSP qui est l'équivalent en python, je travaille beaucoup avec ce langage... mais si tu n'y connais rien, autant utiliser des frameworks haut niveau...)
Axel
[^] # Re: moi j'aurai tendance...
Posté par Spack . Évalué à 1.
Une fois les fichiers correctement édités, les informations contenues seront (sûrements) validés par les autres avant d'être introduite dans la base de données. La base permettra ensuite de retrouver les fichiers rapidement en les classant comme la plupart dans lecteurs audios actuel (Genre, artiste, titre, etc...).
La deuxième partie du projet sera de rendre accessible cette base et là il devrait avoir un peu plus de traffic.
[^] # Re: moi j'aurai tendance...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
http://www.catalystframework.org/
http://jifty.org/view/HomePage
[^] # Re: moi j'aurai tendance...
Posté par Axel R. (site web personnel) . Évalué à 1.
Axel
# HAppS ou HappStack
Posté par paul . Évalué à 2.
# Lift
Posté par hsyl20 (site web personnel) . Évalué à 4.
C'est un framework qui tourne sur la JVM mais qui utilise Scala comme langage. Comme Scala est un des langages les plus intéressants, est statiquement typé et supporte les XML litterals (du XML directement dans le code), ça doit fonctionner plutôt bien (pour être honnête, je ne l'ai jamais utilisé, je ne fais pas de développement web).
# Ma pierre…
Posté par thibault jouannic . Évalué à 3.
Pour apporter ma pierre…
Dis toi qu'un framework est une chose complexe à maîtriser de bout en bout. Par conséquent, si tu souhaites partir sur un framework, choisis-en un une bonne fois pour toute, car il te faudra un certain temps avant d'être vraiment productif (genre, je code à la vitesse de l'éclair sans regarder la doc toutes les 30 secondes).
Après, tous les plus grands frameworks (Django, RoR, Symfony) se valent plus ou moins, et ont chacun leurs avantages et leurs défauts. Si quelqu'un te dit que le framework XXX est vraiment-meilleur-que-les-autres-c'est-celui-la-qu'il-faut-prendre-sans-réfléchir, c'est sans doute qu'il ne sait pas de quoi il parle.
# ou pas
Posté par Alex . Évalué à 4.
Perso, en framework web je ne connais que rails et seaside (en smalltalk)
Je ne te conseillerai pas seaside car écrit dans une langage que (malheureusement) tu trouveras encore moin que ruby.
Néanmoins je le préfére à rails pour une raison: un modèle objet bien plus cohérent: en rails tu as beaucoup plus de "magie" et donc un peu plus de difficultés à comprendre comment tout s'emboite en interne, en seaside chaque objet a son modèle, son contrôleur et sa vue (ça reste clair, vu que smalltalk comporte un très bon ide et sépare le tout en protocole), on voit bien comment tout s'emboite.
voila, juste une petite critique sur rails
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.