Je connais Dabo. J'avais regardé il y a un an ou deux. A l'époque, ça m'avait semblé intéressant, mais encore trop simpliste, par rapport aux besoins. Sans compter, qu'il y a perte de fonctionnalités, et ignorance des accès concurrents en réseau local (une quasi constante, aussi, des frameworks comme sql-alchemy, sql-object, ROR, presque tous les trucs basés sur PHP, etc.)
-- @-salutations
Michel Claveau
Bonsoir !
Je connais Dabo. J'avais regardé il y a un an ou deux. A l'époque, ça
m'avait semblé intéressant, mais encore trop simpliste, par rapport aux
besoins.
Sans compter, qu'il y a perte de fonctionnalités, et ignorance des
accès concurrents en réseau local (une quasi constante, aussi, des
frameworks comme sql-alchemy, sql-object, ROR, presque tous les trucs
basés sur PHP, etc.)
Je connais Dabo. J'avais regardé il y a un an ou deux. A l'époque, ça m'avait semblé intéressant, mais encore trop simpliste, par rapport aux besoins. Sans compter, qu'il y a perte de fonctionnalités, et ignorance des accès concurrents en réseau local (une quasi constante, aussi, des frameworks comme sql-alchemy, sql-object, ROR, presque tous les trucs basés sur PHP, etc.)
-- @-salutations
Michel Claveau
Bruno Desthuilliers
Enfin bref, tout ça n'est finalement qu'une question de point de vue et d'adéquation entre goûts, habitudes, besoins, expérience ...
Exactement !-).
Une petite précision quand même, je ne cherchais pas à faire de comparaisons entre Django et les autres framework web Python que je connais pas assez bien (encore une fois à cause du peu de temps dispo).
J'ai choisi Django de manière très intuitive au départ, et jusque là il n'y a pas de projet que je n'ai pas réussi et avec une grande aisance (d'autant plus que je suis un débutant en python, en prog objet et je ne suis pas un développeur de formation).
C'est effectivement une des forces de Django (liée entre autres à la qualité de la doc et à la très forte intégration), et une des raisons de son succès : c'est facile de démarrer pour qui n'est pas un développeur chevronné. Mais ce qui est une force à un niveau devient une faiblesse à un autre, et il est intéressant de constaté que Pylons, qui est en quelques sortes à l'autre extrême attire plutôt des développeurs expérimentés pour qui la flexibilité, la capacité d'intervenir à à peu près n'importe quel stade du traitement, et la possibilité de faire les chose à leur façon plutôt que de se voire imposer un mode opératoire par le framework sont plus importants que la facilité de prise en main.
Le jour ou un projet me semblera trop compliqué à réaliser avec Django alors j'évaluerais les autres.
Peut-être devrais tu ne pas attendre ce moment pour jeter un oeil ailleurs ? Pas nécessairement pour changer d'outil, mais pour élargir un peu ton horizon...
Mes deux centimes...
Enfin bref, tout ça n'est finalement qu'une question de point de vue
et d'adéquation entre goûts, habitudes, besoins, expérience ...
Exactement !-).
Une petite précision quand même, je ne cherchais pas à faire de
comparaisons entre Django et les autres framework web Python que je
connais pas assez bien (encore une fois à cause du peu de temps
dispo).
J'ai choisi Django de manière très intuitive au départ, et jusque là
il n'y a pas de projet que je n'ai pas réussi et avec une grande
aisance (d'autant plus que je suis un débutant en python, en prog
objet et je ne suis pas un développeur de formation).
C'est effectivement une des forces de Django (liée entre autres à la
qualité de la doc et à la très forte intégration), et une des raisons de
son succès : c'est facile de démarrer pour qui n'est pas un développeur
chevronné. Mais ce qui est une force à un niveau devient une faiblesse à
un autre, et il est intéressant de constaté que Pylons, qui est en
quelques sortes à l'autre extrême attire plutôt des développeurs
expérimentés pour qui la flexibilité, la capacité d'intervenir à à peu
près n'importe quel stade du traitement, et la possibilité de faire les
chose à leur façon plutôt que de se voire imposer un mode opératoire par
le framework sont plus importants que la facilité de prise en main.
Le jour ou un projet me semblera trop compliqué à réaliser avec Django
alors j'évaluerais les autres.
Peut-être devrais tu ne pas attendre ce moment pour jeter un oeil
ailleurs ? Pas nécessairement pour changer d'outil, mais pour élargir un
peu ton horizon...
Enfin bref, tout ça n'est finalement qu'une question de point de vue et d'adéquation entre goûts, habitudes, besoins, expérience ...
Exactement !-).
Une petite précision quand même, je ne cherchais pas à faire de comparaisons entre Django et les autres framework web Python que je connais pas assez bien (encore une fois à cause du peu de temps dispo).
J'ai choisi Django de manière très intuitive au départ, et jusque là il n'y a pas de projet que je n'ai pas réussi et avec une grande aisance (d'autant plus que je suis un débutant en python, en prog objet et je ne suis pas un développeur de formation).
C'est effectivement une des forces de Django (liée entre autres à la qualité de la doc et à la très forte intégration), et une des raisons de son succès : c'est facile de démarrer pour qui n'est pas un développeur chevronné. Mais ce qui est une force à un niveau devient une faiblesse à un autre, et il est intéressant de constaté que Pylons, qui est en quelques sortes à l'autre extrême attire plutôt des développeurs expérimentés pour qui la flexibilité, la capacité d'intervenir à à peu près n'importe quel stade du traitement, et la possibilité de faire les chose à leur façon plutôt que de se voire imposer un mode opératoire par le framework sont plus importants que la facilité de prise en main.
Le jour ou un projet me semblera trop compliqué à réaliser avec Django alors j'évaluerais les autres.
Peut-être devrais tu ne pas attendre ce moment pour jeter un oeil ailleurs ? Pas nécessairement pour changer d'outil, mais pour élargir un peu ton horizon...
Mes deux centimes...
olive
On 14 juin, 08:41, Bruno Desthuilliers <bruno. wrote:
Peut-être devrais tu ne pas attendre ce moment pour jeter un oeil ailleurs ? Pas nécessairement pour changer d'outil, mais pour élargir un peu ton horizon...
J'aimerais bien en avoir le temps ... et le manque de temps est l'une des principales raisons pour laquelle j'utilise Django.
Merci en tous cas pour ton point de vue (qui conforte mon opinion à ce sujet et qui ne manquera pas de conforter, a juste titre, celle des développeurs chevronnés qui se sont fait leur idée propre sur la manière de concevoir une appli).
Olive.
On 14 juin, 08:41, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.com> wrote:
Peut-être devrais tu ne pas attendre ce moment pour jeter un oeil
ailleurs ? Pas nécessairement pour changer d'outil, mais pour élargir un
peu ton horizon...
J'aimerais bien en avoir le temps ...
et le manque de temps est l'une des principales raisons pour laquelle
j'utilise Django.
Merci en tous cas pour ton point de vue (qui conforte mon opinion à ce
sujet
et qui ne manquera pas de conforter, a juste titre, celle des
développeurs chevronnés
qui se sont fait leur idée propre sur la manière de concevoir une
appli).
On 14 juin, 08:41, Bruno Desthuilliers <bruno. wrote:
Peut-être devrais tu ne pas attendre ce moment pour jeter un oeil ailleurs ? Pas nécessairement pour changer d'outil, mais pour élargir un peu ton horizon...
J'aimerais bien en avoir le temps ... et le manque de temps est l'une des principales raisons pour laquelle j'utilise Django.
Merci en tous cas pour ton point de vue (qui conforte mon opinion à ce sujet et qui ne manquera pas de conforter, a juste titre, celle des développeurs chevronnés qui se sont fait leur idée propre sur la manière de concevoir une appli).
Olive.
rejoc
le 13.06.2007 21:27 Laurent Pointal a écrit:
Je n'apprécie pas trop non plus les object-mappers (mauvaise expérience avec une reprise de code Java utilisant Hibernate - cf un post dans pythonfr). Ils font perdre l'accès à un langage qui peut être très puissant. Je peux replacer ici l'exemple du mapper qui fait +10% sur les prix en chargeant toutes les données en mémoire avant de faire des update... alors qu'en SQL ça peut être fait directement côté serveur... Il est évident que chaque fois qu'on ajoute une couche on perd en perf.
Maintenant, rien n'empêche, dans une phase d'optimisation, "d'aider" l'ORM à travailler en mettant quelques appels "sql purs" là où ça sert (mais on risque de perdre l'indépendance de la bdd dont il est question plus bas... on ne gagne jamais sur tous les tableaux).
Et puis, même sans ORM, j'ai vu pas mal d'appli qui récupéraient des tables (presque) entières pour n'afficher que 2 lignes ou faire 3 updates...
Dans le cas de sqlAlchemy, je n'ai pas encore eu à l'utiliser, mais j'y vois au moins un intérêt: pouvoir passer d'un SGBDR à un autre sans avoir à se tapper les différences, mineures mais réelles, entre les implémentations de la DB-API2. C'est en effet un intérêt. L'autre que j'y vois c'est le fait qu'on ne
se préoccupe plus trop de "comment c'est stocké en dessous". On manipule des objets et l'ORM en assure la persistance.
Laurent.
le 13.06.2007 21:27 Laurent Pointal a écrit:
Je n'apprécie pas trop non plus les object-mappers (mauvaise expérience avec
une reprise de code Java utilisant Hibernate - cf un post dans pythonfr).
Ils font perdre l'accès à un langage qui peut être très puissant. Je peux
replacer ici l'exemple du mapper qui fait +10% sur les prix en chargeant
toutes les données en mémoire avant de faire des update... alors qu'en SQL
ça peut être fait directement côté serveur...
Il est évident que chaque fois qu'on ajoute une couche on perd en perf.
Maintenant, rien n'empêche, dans une phase d'optimisation, "d'aider"
l'ORM à travailler en mettant quelques appels "sql purs" là où ça sert
(mais on risque de perdre l'indépendance de la bdd dont il est question
plus bas... on ne gagne jamais sur tous les tableaux).
Et puis, même sans ORM, j'ai vu pas mal d'appli qui récupéraient des
tables (presque) entières pour n'afficher que 2 lignes ou faire 3 updates...
Dans le cas de sqlAlchemy, je n'ai pas encore eu à l'utiliser, mais j'y vois
au moins un intérêt: pouvoir passer d'un SGBDR à un autre sans avoir à se
tapper les différences, mineures mais réelles, entre les implémentations de
la DB-API2.
C'est en effet un intérêt. L'autre que j'y vois c'est le fait qu'on ne
se préoccupe plus trop de "comment c'est stocké en dessous". On manipule
des objets et l'ORM en assure la persistance.
Je n'apprécie pas trop non plus les object-mappers (mauvaise expérience avec une reprise de code Java utilisant Hibernate - cf un post dans pythonfr). Ils font perdre l'accès à un langage qui peut être très puissant. Je peux replacer ici l'exemple du mapper qui fait +10% sur les prix en chargeant toutes les données en mémoire avant de faire des update... alors qu'en SQL ça peut être fait directement côté serveur... Il est évident que chaque fois qu'on ajoute une couche on perd en perf.
Maintenant, rien n'empêche, dans une phase d'optimisation, "d'aider" l'ORM à travailler en mettant quelques appels "sql purs" là où ça sert (mais on risque de perdre l'indépendance de la bdd dont il est question plus bas... on ne gagne jamais sur tous les tableaux).
Et puis, même sans ORM, j'ai vu pas mal d'appli qui récupéraient des tables (presque) entières pour n'afficher que 2 lignes ou faire 3 updates...
Dans le cas de sqlAlchemy, je n'ai pas encore eu à l'utiliser, mais j'y vois au moins un intérêt: pouvoir passer d'un SGBDR à un autre sans avoir à se tapper les différences, mineures mais réelles, entre les implémentations de la DB-API2. C'est en effet un intérêt. L'autre que j'y vois c'est le fait qu'on ne
se préoccupe plus trop de "comment c'est stocké en dessous". On manipule des objets et l'ORM en assure la persistance.
Laurent.
rejoc
le 13.06.2007 15:49 MCI a écrit:
Bonjour !
g1 = Groupe.get_by(Groupe.c.nom=="groupe 1") select * from g1 where nom="groupe 1"
Désolé, mais je trouve la ligne SQL (2e) nettement plus lisible.
L'intérêt n'est pas tellement sur cet appel-là mais sur les suivants :
e = g1.elements , par exemple, évite d'avoir à se taper un select * from element where groupe_id=1
Ca évite aussi de devoir apprendre les subtilités des dialectes SQL des différentes BDD... Et donc, comme tout outil qui se veut générique, ça à des limitations proches du PGCD des outils que ça recouvre. A nous utilisateurs de peser le pour et le contre.
le 13.06.2007 15:49 MCI a écrit:
Bonjour !
g1 = Groupe.get_by(Groupe.c.nom=="groupe 1")
select * from g1 where nom="groupe 1"
Désolé, mais je trouve la ligne SQL (2e) nettement plus lisible.
L'intérêt n'est pas tellement sur cet appel-là mais sur les suivants :
e = g1.elements , par exemple, évite d'avoir à se taper un
select * from element where groupe_id=1
Ca évite aussi de devoir apprendre les subtilités des dialectes SQL des
différentes BDD...
Et donc, comme tout outil qui se veut générique, ça à des limitations
proches du PGCD des outils que ça recouvre. A nous utilisateurs de peser
le pour et le contre.
g1 = Groupe.get_by(Groupe.c.nom=="groupe 1") select * from g1 where nom="groupe 1"
Désolé, mais je trouve la ligne SQL (2e) nettement plus lisible.
L'intérêt n'est pas tellement sur cet appel-là mais sur les suivants :
e = g1.elements , par exemple, évite d'avoir à se taper un select * from element where groupe_id=1
Ca évite aussi de devoir apprendre les subtilités des dialectes SQL des différentes BDD... Et donc, comme tout outil qui se veut générique, ça à des limitations proches du PGCD des outils que ça recouvre. A nous utilisateurs de peser le pour et le contre.
jean-marc pouchoulon
Bonjour,
ya t il des courageux qui utilise Elixir l'excellllllent ORM ?
et qu'en pensez vous ?
si vous avez des retour d'experience, idéee remarques ...
A+ chris
Bonjour , dans le même registre j'ai essayé sqlsoup, une surcouche de sqlalchemy qui permet de se mapper simplement et rapidement une base existante.
http://www.sqlalchemy.org/trac/wiki/SqlSoup
Je me suis amusé à me connecter à une base glpi ( inventaire machine ) et à faire quelques extractions.
from sqlalchemy.ext.sqlsoup import SqlSoup
# Connexion à la base de données db = SqlSoup('mysql://user:/glpi')
# Permet de voir les requêtes sql générées db.engine.echo = True
# jointure pour avoir l'ensemble des machines avec leurs localisations
# ajout de l'os j2j = db.join(db.glpi_dropdown_os, jointure, db.glpi_computers.c.os=Û.glpi_dropdown_os.ID)
# ajout de la version de l'os j3j = db.join(db.glpi_dropdown_os_version, j2j, db.glpi_computers.c.os=Û.glpi_dropdown_os.ID)
# Select de l'ensemble des machines select_machine = db.with_labels(j3j).select()
# List comprehensionss machines = [s for s in select_machine] serveurs = [s for s in select_machine if s.glpi_computers_location==1] ...
Je me suis acheté un livre sur turbogears qui a le mérite d'exister (il est bien d'avoir une doc papier), la liste relative à ce produit est active et laisse augurer une bonne vitalité du produit. Ceci dit la doc de django semble très bien faite et plus carré que tg. tg a l'avantage et les inconvénients d'une structure composite. Après ne développant que très occasionnellement je laisse au vrai dev juger de ces produits mais sur le principe bénéficier des List Comprehensions de Python sans sql c'est vraiment sympa.
Bonne soirée
Bonjour,
ya t il des courageux qui utilise Elixir l'excellllllent ORM ?
et qu'en pensez vous ?
si vous avez des retour d'experience, idéee remarques ...
A+
chris
Bonjour ,
dans le même registre j'ai essayé sqlsoup, une surcouche de sqlalchemy
qui permet de se mapper simplement et rapidement une base existante.
http://www.sqlalchemy.org/trac/wiki/SqlSoup
Je me suis amusé à me connecter à une base glpi ( inventaire machine )
et à faire quelques extractions.
from sqlalchemy.ext.sqlsoup import SqlSoup
# Connexion à la base de données
db = SqlSoup('mysql://user:passwd@localhost/glpi')
# Permet de voir les requêtes sql générées
db.engine.echo = True
# jointure pour avoir l'ensemble des machines avec leurs localisations
# ajout de l'os
j2j = db.join(db.glpi_dropdown_os,
jointure,
db.glpi_computers.c.os=Û.glpi_dropdown_os.ID)
# ajout de la version de l'os
j3j = db.join(db.glpi_dropdown_os_version,
j2j,
db.glpi_computers.c.os=Û.glpi_dropdown_os.ID)
# Select de l'ensemble des machines
select_machine = db.with_labels(j3j).select()
# List comprehensionss
machines = [s for s in select_machine]
serveurs = [s for s in select_machine if s.glpi_computers_location==1]
...
Je me suis acheté un livre sur turbogears qui a le mérite d'exister (il
est bien d'avoir une doc papier), la liste relative à ce produit est
active et laisse augurer une bonne vitalité du produit.
Ceci dit la doc de django semble très bien faite et plus carré que tg.
tg a l'avantage et les inconvénients d'une structure composite.
Après ne développant que très occasionnellement je laisse au vrai dev
juger de ces produits mais sur le principe bénéficier des List
Comprehensions de Python sans sql c'est vraiment sympa.
# ajout de l'os j2j = db.join(db.glpi_dropdown_os, jointure, db.glpi_computers.c.os=Û.glpi_dropdown_os.ID)
# ajout de la version de l'os j3j = db.join(db.glpi_dropdown_os_version, j2j, db.glpi_computers.c.os=Û.glpi_dropdown_os.ID)
# Select de l'ensemble des machines select_machine = db.with_labels(j3j).select()
# List comprehensionss machines = [s for s in select_machine] serveurs = [s for s in select_machine if s.glpi_computers_location==1] ...
Je me suis acheté un livre sur turbogears qui a le mérite d'exister (il est bien d'avoir une doc papier), la liste relative à ce produit est active et laisse augurer une bonne vitalité du produit. Ceci dit la doc de django semble très bien faite et plus carré que tg. tg a l'avantage et les inconvénients d'une structure composite. Après ne développant que très occasionnellement je laisse au vrai dev juger de ces produits mais sur le principe bénéficier des List Comprehensions de Python sans sql c'est vraiment sympa.
