[Django VS Rails] Donnez des arguments

bref pourquoi choisir django et pas rails ? :p

Citation:

---

Envoyé par kedare

bref pourquoi choisir django et pas rails ? :p

---

Pourquoi choisir Rails et pas Django?

pour tout ce qui est dit avant :)

et pour SOAP jamais fait alors ?

Citation:

---

Envoyé par GnuVince

Pourquoi choisir Rails et pas Django?

---

parceque c'est plus utilisé , il y a plus de plugins :p

Citation:

---

Envoyé par kedare

parceque c'est plus utilisé , il y a plus de plugins :p

---

C'est aussi plus lent, plus gourmand en mémoire, ça utilise un langage moins connu qui possède moins de librairies, ça utilise un mix de serveurs web (Apache + Mongrel + ngnix) pour rouler les applications et la documentation est mauvaise.

Si tu te fiais tout le temps à la popularité pour faire tes choix de technologies, tu serait encore sur PHP et Ruby on Rails aurait jamais connu la popularité qu'il a présentement.

Django possède des avantages qui ont déjà été mentionné. Visite le site de Django pour plus d'informations.

Citation:

---

Si tu te fiais tout le temps à la popularité pour faire tes choix de technologies, tu serait encore sur PHP et Ruby on Rails aurait jamais connu la popularité qu'il a présentement.

---

+1 ;)

Citation:

---

Envoyé par GnuVince

Si tu te fiais tout le temps à la popularité pour faire tes choix de technologies, tu serait encore sur PHP et Ruby on Rails aurait jamais connu la popularité qu'il a présentement.

---

c'est une des raisons du choix de Django par ma boite, récupérer despersonne élitiste plutot qu'une masse à la PHP, la notoriété + facilité pose quelques fois des sacrés problemes ...

En tout cas GnuVince ton prosélytisme donne bien envie d'essayer Django :D

@++

Citation:

---

Envoyé par kedare

j'aime bien le systeme de sous-template de rails (enfin je sait pas si on peut appeler ca comme ca) , je parle des render :partial, qui permet de re-utiliser le meme template dans une partie de page differentes , il doit y avoir la meme chose chez django mais j'ai pas trouvé

---

Pour inclure un Template dans un autre on utilise le tag "ssi" ou tout simplement "include". Ceci dis je trouve cette façon de faire pas très propres car au final on se perd vite à la relecture du Template.

Je préfère, au lieu d'insérer de gros morceaux dans un Template, découper en plus petit en créant des Tags de Template personnalisés, ainsi on garde un maximum d'information dans le Template tout en diminuant son encombrement.

Sinon je ne sais pas si c'est le cas de Rail, mais une fonction que je trouve excellente en Django c'est le fait qu'un Template peut hériter d'un autre :mrgreen: c'est vachement pratique et très bien pensé, ainsi dans les Template parents on peut créer plein de block vide, qu'on remplira à l'envi dans les sous Template.

Citation:

---

Envoyé par kedare

par contre il y a pas mal de chose que je n'aime pas dans python , deja le fait que les variable locale privée doivent commencer par un _ , exemple : _name ....

---

variables locales et privés ce n'est pas la même chose.
Les variables locales, c'est à dire celles dont la portée ne dépasse pas la fonction ou la méthode où elles sont définie ne sont soumises aucunes règles d'écriture particulières.
Par contre quand on commence le nom d'une méthode ou attribue par _ le nom en question est remplacé par l'interpréteur à l'exécution, les rendant ainsi (méthode ou attribue) non accessible à l'extérieur de la classe.

Citation:

---

Envoyé par kedare

aussi le fait que tout les objets n'hérite pas d'object est etrange ...

---

En python tout est objet, même les classes héritent du type objet.

Citation:

---

Envoyé par GnuVince

Vu que la AJAX c'est plus le côté design et que c'est mon co-équipier qui s'en occupe, je suis moins au courant. On utilise jQuery et ça semble aller parfaitement bien.

---

Justement je suis en train de regarder quelle solution choisir, ce matin j'ai jeté un coup d'œil à JQuery, que j'ai trouvé très bien (pour ce que j'ai à en faire) j'ai bien aimé le fait que tout le code JavaScript est regroupé en un seul endroit (au début) et non éparpillé un peu partout dans la page.
Si après votre utilisation de cette lib avec Django pour avez des recommandations ou des mises en garde particulières à faire, je serai preneur. (d’avance merci).

Citation:

---

Envoyé par kedare

bref pourquoi choisir django et pas rails ? :p

---

Ça dépend de beaucoup de choses:
- De l'utilisation qu'on a à en faire.
- De notre degré de connaissance (en Python ou en Ruby).
- De l'environnement dans lequel on va implémenter la solution.
- De notre façon de penser et de travailler.
etc etc.

A mon avis le monde de l'information est assez large pour accepter les deux Framework et bien plus encore, ce qui compte au final ce n'est pas de savoir le quelle est le meilleur mais plutôt lequel réponds le mieux à nos besoins et a notre problème du moment et/ou futur.

Ozatorenator je penses que tu essais d'expliquer des concepts a quelqu'un de plus callé que toi, à mon avis kedare a déjà un bon paquet d 'experience de ruby/python et tu n'as pas du comprendre ce qu'il dit vis à vis de l'héritage d "object"

En effet en python il y a 2 notation d'objet, la nouvelle permetant des manipulations beaucoup plus puissante que l'ancienne et surtout beaucoup plus "objet" (surtout niveau typage) mais pour utiliser des classes de ce type il faut forcer l'héritage d' "object"

un exemple sera plus claire :

Code:

---

1 2 3 4 5 6 7 8

class Old:pass class New(object):pass   old = Old() new = New()   print type(old) print type(new)

---

print :

Code:

---

1 2	<type 'instance'> <class '__main__.New'>

---

dans l'ancienne notation les objet etait des "instance d'une classe" alors que maintenant c clairement une "instance de class New"
Il y a égallement de nouvelle possibilités niveau metaprogrammation et aussi la superbe fonction __new__().

Bref 2 systeme de class cote a cote c'est un peu bordelique... python souffre beaucoup d'une trop forte compatibilité ascendante qui empeche d'avoir un language homogéne ...

Enfin bon vivement python 3.0 :)

A partir du Python 2.2 le type prédéfini object est l’ancêtre de tout les types prédéfinis et de toutes les classes. En d’autre terme tout ce qui existe dans python hérite d’object.
En reprenant ton exemple cela donnera un truc de ce genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

>>> class UneClasse: ... pass ... >>> class UnType(object): ... pass ... >>> >>> uneClasse = UneClasse() >>> unType = UnType() >>> >>> isinstance(UneClasse, object) True >>> isinstance(UnType, object) True >>> isinstance(uneClasse, object) True >>> isinstance(unType, object) True

---

Par contre les deux objets UneClasse et UnType sont différent dans le sens où le premier est de type 'classobj' mais le deuxieme est de type 'type' mais n’en reste pas moins que ce sont tout deux des descendant du premier type ‘object’.

Code:

---

1 2 3 4 5 6 7 8

>>> isinstance(UneClasse, type) False >>> isinstance(UnType, type) True >>> type(UneClasse) <type 'classobj'> >>> type(UnType) <type 'type'>

---

Ainsi en précisant explicitement qu'une classe hérite du type 'object' on en fait un 'type' ce qui est logique car 'object' est de type 'type'. :mrgreen:

mouarf tu viens de me prouver que c encore plus bordelique que ce que je pensais ! :aie:

tu trouve ca normal ?

Code:

---

1 2 3 4 5 6

class New(object):pass class Old:pass   print issubclass(New, object) print issubclass(Old, object) print Old is object

---

Code:

---

1 2 3

True False False

---

C normal que les instance de Old soit une instance d'object sans que Old soit cette classe ou une sous classe d'object ? moi je ne trouve pas cela normal du tout ...

autre chose si Old est une instance d'object (c'est renvoyé comme True par python) pkoi n'as t'on pas acces aux membres d'object ?

Code:

---

1 2 3 4 5

class Old:pass old = Old() print isinstance(Old, object) print dir(object) print Old.__new__()

---

Code:

---

1 2 3 4 5 6

True ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__'] Traceback (most recent call last): File "C:\Users\Anthyme\Projects\Pydev\Eneide\src\test.py", line 5, in <module> print Old.__new__() AttributeError: class Old has no attribute '__new__'

---

Escuse moi mais une instance d'une classe qui n'as pas acces aux membre de cette classe (a moins d'etre obliger de "forcer" l'héritage) c'est tout sauf de la POO et c'est vraiment deguelasse...

Certe en jouant sur les mot ce sont tous des instances d'object comme tu le dis mais malgres ce que tu dis les classes n'héritent pas d'object et ce paradoxe est vraiment moche...

legere erreur de ma part mais ca revient au même :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class Old:pass old = Old() print isinstance(Old, object) print dir(object) print old.__new__()     True ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__'] Traceback (most recent call last): File "C:\Users\Anthyme\Projects\Pydev\Eneide\src\test.py", line 5, in <module> print old.__new__() AttributeError: Old instance has no attribute '__new__'

---

Citation:

---

Envoyé par Ozatorenator

En python tout est objet, même les classes héritent du type objet.

---

Code:

---

1 2	>>> super(str) #pourquoi pas str.super ? <super: <class 'str'>, NULL>

---

la faut croire que non
mais la :

Code:

---

1 2	>>> isinstance(str,object) True

---

la faut croire que oui ....
c'est vraiment floue

puis peut-on modifier les classes a la volée en python ?
par exemple en ruby je veut ajouter Object#super comme Object#superclass,
j'ai juste a faire :

Code:

---

1 2 3 4 5

class Object def super self.superclass end end

---

c'est possible en python ?

Citation:

---

Envoyé par kedare

Code:

---

1 2	>>> super(str) #pourquoi pas str.super ? <super: <class 'str'>, NULL>

---

---

super ne retourne pas la classe parent. Mais crée une super classe/objet.
super n'est pas une fonction mais un type prédéfini, il n'est pas utilisé pour répondre à la question "quelle est la classe parent de cette classe ?" mais est utilisée pour créer une super-class/objet, cette super classe/objet est utilisée après pour appeler les méthodes ancêtres et cacher ainsi toute la chaine d'héritage. Ceci est nécessaire dans certain cas car python gère l'héritage multiple de classes et super permet de résoudre le problème de l'appel coopératif à des méthodes de super classe.


Pour des details sur ce probleme d'appel cooperatif voir ici:
http://www.python.org/download/relea...o/#cooperation

Citation:

---

Envoyé par kedare

#pourquoi pas str.super ?

---

C'est str.__bases__

Citation:

---

Envoyé par kedare

puis peut-on modifier les classes a la volée en python ?
par exemple en ruby je veut ajouter Object#super comme Object#superclass,
j'ai juste a faire :

Code:

---

1 2 3 4 5

class Object def super self.superclass end end

---

c'est possible en python ?

---

Oui, on peut en creer à la volé, les midifier et rajouter des classes de bases à une classe.
Un peu comme ça:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

>>> class A:pass ... >>> class B: ... def uneMethodDeChezB(self): ... pass ... >>> class C: ... def uneMethodDeChezC(self): ... pass ... >>> A.__bases__ += (B,C) >>> A.uneMethodDeChezB <unbound method A.uneMethodDeChezB> >>> A.uneMethodDeChezC <unbound method A.uneMethodDeChezC>

---

Dans python il y a la notion de type et de classe. A partir de la version 2.2 on a tenté d'unifier les deux notions, ce qui fait que maintenant un type est une classe mais une classe qui n'hérite pas explicitement de object n'est pas un type, néanmoins ca reste une class (type classobj) qui lui hérite bien de object.
En claire tout est objets, et comme il est dis plus haut, ça sera encore plus renforcé dans les futurs versions.
Ceci étant dis, tout ceci est du domaine du détail, et en pratique les quelques imperfections qui subsistes dans le model objet python ne réduisent en rien sa puissance, ni son champs d’utilisation.

mouais, je prefere quand meme ruby :p

Citation:

---

Envoyé par kedare

mouais, je prefere quand meme ruby :p

---

Ben correct.

Citation:

---

Envoyé par kedare

parceque c'est plus utilisé , il y a plus de plugins :p

---

Ca n'est pas un argument et ça n'en sera jamais un.
C'est le même problème avec php, ou jquery, ce n'est pas la communauté qui fait le projet.

Dans l'absolu, je trouve django moins contraignant, on est vraiment libre de faire à sa guise. Django est un framework qui propose des outils plutôt que des conventions.

Y'a aussi un fossé considérable quand à la mise en place d'environnements de developpement. (en grande partie grace à WSGI)

Il n'empeche que j'aime beaucoup Ruby, y'a pas mal de features interessantes, et c'est un langage très puissant.

Ps : Et j'ajouterais que la majorité des remarques sur le langage de template sont invalides puisqu'on peut choisir le système de son choix (il en existe une douzaine il me semble)