En fait que ce sois SQLAlchemy ou SQLOBject ce qui manque c'est des exemples autres que insert et select (je comprend aussi que c'est pas la partie la plus marrante a faire :) )
Pour ce qui est de la partie "basse" (non-orm) de SQLAlchelmy, tu n'a pas du chercher beaucoup:
Si tu utilises la partie ORM (directement ou via Elixir), tu n'a pas à te soucier de ça, c'est pris en charge par l'ORM (cf l'exemple donné par rejoc).
Ainsi j'ai eu un peu de mal a comprendre certaine notamment comment on utilise les objects retournés par les requetes et l'appel de certaine fonctions
Dans quel cadre ?
Avec des choses plus compliqué du style ( update ... where truc=1 ) ou tout ce qui fait la beauté de sql
Dans quel cadre ?
(snip)
En fait que ce sois SQLAlchemy ou SQLOBject ce qui manque c'est des
exemples autres que insert et select (je comprend aussi que c'est pas la
partie la plus marrante a faire :) )
Pour ce qui est de la partie "basse" (non-orm) de SQLAlchelmy, tu n'a
pas du chercher beaucoup:
Si tu utilises la partie ORM (directement ou via Elixir), tu n'a pas à
te soucier de ça, c'est pris en charge par l'ORM (cf l'exemple donné par
rejoc).
Ainsi j'ai eu un peu de mal a comprendre certaine notamment comment on
utilise les objects retournés par les requetes et l'appel de certaine
fonctions
Dans quel cadre ?
Avec des choses plus compliqué du style ( update ... where truc=1 )
ou tout ce qui fait la beauté de sql
En fait que ce sois SQLAlchemy ou SQLOBject ce qui manque c'est des exemples autres que insert et select (je comprend aussi que c'est pas la partie la plus marrante a faire :) )
Pour ce qui est de la partie "basse" (non-orm) de SQLAlchelmy, tu n'a pas du chercher beaucoup:
Si tu utilises la partie ORM (directement ou via Elixir), tu n'a pas à te soucier de ça, c'est pris en charge par l'ORM (cf l'exemple donné par rejoc).
Ainsi j'ai eu un peu de mal a comprendre certaine notamment comment on utilise les objects retournés par les requetes et l'appel de certaine fonctions
Dans quel cadre ?
Avec des choses plus compliqué du style ( update ... where truc=1 ) ou tout ce qui fait la beauté de sql
Dans quel cadre ?
olive
On 13 juin, 11:26, Bruno Desthuilliers <bruno. wrote:
Salut,
il y a aussi sqlObject, réputé plus "facil" que sqlAlchemy.
Et notoirement plus limité.
d'accord
Pour ma part je suis habitué à l'ORM de Django qui répond parfait ement à mes modestes besoins (en termes de compexité de schéma et requ ête, mais pas de performance ni de volume).
Au fait, toi qui cherche un équivalent à RoR, Django (djangoproject.com) est à mon avis bien supérieur à différents niveaux.
Heu... Tu as réellement développé quelque chose (je veux dire, de non-trivial) avec Rails ?
Non, javoue m'être rangé à l'avis général de ceux qui sont justem ent passé de RoR à Django, TurboGear ou Pylon pour tout ce qui non trivial. Je n'ai hélas pas le temps de tester à fond tous les frameworks.
Django partage avec Rails l'inconvénient d'être un monolithe. En deho rs
Quand tu dis monolithe, moi j'entend : "piles incluses" (battery included), cohérence du code et de la doc, facilité de mise à jour et de maintenance ... De plus Django permet le choix d'autres "template engine", ORM (sqlAlchemy est en cours d'intégration même si celq ne semble pas être une priorité depuis qu'il existe un backend pour Oracle)
de ça - et bien que Django soit un très bon produit dans son genre -, j'avoue ne pas voir où est la "supériorité".
Allons, allons Bruno ! et Python alors ?
Mais aussi Lighty, Apache avec mod_python ou wsgi, l'interface d'admin dynamique, la qualité de la doc et de la communauté etc, etc (encore une fois l'évangélisme n'est pas mon fort).
On 13 juin, 11:26, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.com> wrote:
Salut,
il y a aussi sqlObject, réputé plus "facil" que sqlAlchemy.
Et notoirement plus limité.
d'accord
Pour ma part je suis habitué à l'ORM de Django qui répond parfait ement
à mes modestes besoins (en termes de compexité de schéma et requ ête,
mais pas de performance ni de volume).
Au fait, toi qui cherche un équivalent à RoR, Django
(djangoproject.com) est à mon avis bien supérieur à différents
niveaux.
Heu... Tu as réellement développé quelque chose (je veux dire, de
non-trivial) avec Rails ?
Non, javoue m'être rangé à l'avis général de ceux qui sont justem ent
passé de RoR à Django,
TurboGear ou Pylon pour tout ce qui non trivial.
Je n'ai hélas pas le temps de tester à fond tous les frameworks.
Django partage avec Rails l'inconvénient d'être un monolithe. En deho rs
Quand tu dis monolithe, moi j'entend : "piles incluses" (battery
included), cohérence du code et de la doc,
facilité de mise à jour et de maintenance ...
De plus Django permet le choix d'autres "template engine", ORM
(sqlAlchemy est en cours d'intégration même si celq ne semble pas être
une priorité depuis qu'il existe un backend pour Oracle)
de ça - et bien que Django soit un très bon produit dans son genre -,
j'avoue ne pas voir où est la "supériorité".
Allons, allons Bruno ! et Python alors ?
Mais aussi Lighty, Apache avec mod_python ou wsgi,
l'interface d'admin dynamique, la qualité de la doc et de la
communauté
etc, etc (encore une fois l'évangélisme n'est pas mon fort).
On 13 juin, 11:26, Bruno Desthuilliers <bruno. wrote:
Salut,
il y a aussi sqlObject, réputé plus "facil" que sqlAlchemy.
Et notoirement plus limité.
d'accord
Pour ma part je suis habitué à l'ORM de Django qui répond parfait ement à mes modestes besoins (en termes de compexité de schéma et requ ête, mais pas de performance ni de volume).
Au fait, toi qui cherche un équivalent à RoR, Django (djangoproject.com) est à mon avis bien supérieur à différents niveaux.
Heu... Tu as réellement développé quelque chose (je veux dire, de non-trivial) avec Rails ?
Non, javoue m'être rangé à l'avis général de ceux qui sont justem ent passé de RoR à Django, TurboGear ou Pylon pour tout ce qui non trivial. Je n'ai hélas pas le temps de tester à fond tous les frameworks.
Django partage avec Rails l'inconvénient d'être un monolithe. En deho rs
Quand tu dis monolithe, moi j'entend : "piles incluses" (battery included), cohérence du code et de la doc, facilité de mise à jour et de maintenance ... De plus Django permet le choix d'autres "template engine", ORM (sqlAlchemy est en cours d'intégration même si celq ne semble pas être une priorité depuis qu'il existe un backend pour Oracle)
de ça - et bien que Django soit un très bon produit dans son genre -, j'avoue ne pas voir où est la "supériorité".
Allons, allons Bruno ! et Python alors ?
Mais aussi Lighty, Apache avec mod_python ou wsgi, l'interface d'admin dynamique, la qualité de la doc et de la communauté etc, etc (encore une fois l'évangélisme n'est pas mon fort).
olive
On 12 juin, 16:49, chris wrote:
Salut,
il y a aussi sqlObject, réputé plus "facil" que sqlAlchemy.
Pour ma part je suis habitué à l'ORM de Django qui répond parfait ement à mes modestes besoins (en termes de compexité de schéma et requ ête, mais pas de performance ni de volume).
Au fait, toi qui cherche un équivalent à RoR, Django (djangoproject.com) est à mon avis bien supérieur à différents niveaux.
Mais comme l'évangélisme n'est pas ma tasse de thé, je te laisse découvrir la bête ... ... après ça, reviens poser des questions sur Django quand tu veux, j'y répondrais de mon mieux.
Olive.
J'ai decouvert django j'ai un petit peut testé pour voir la bete c'est bien mais j'ai pas compris certaine choses Par exemple : le coté admin => c'est génial mais moi je veux la même chose coté utilisateur et je comprends pas
Je ne vois pas ce qui t'en empêche! mais il est vrai que cela sera plus facile avec la 1.0 imminente qui permettra de personnaliser pus facilement l'interface d'admin grâce au nouveau système de gestion de formulaire déjà présent dans la 0.96.
la plupart des tutoriels explique comment developper des templates mais c'est pas genial
L'idée est d'encourager l'écriture des règles business dans le fichier views.py ou de définir de nouveaux "template tags" de manière à affranchir le web designer du code. C'est pour cela que le système template semble limité, mais rien ne t'empêche d'adopter un autre systèmede template et mélanger code et présentation àla PHP.
Bon comme je suis pas pressé j'attends un peu la maturité
Le produit est déjà très mature il ne faut ce fier au numéro de version, d'autres seraient déjà en 9.6 avec la même maturité.
Mais il est vrai que l'on y verra encore plus claire avec 10.0 (euh... non je voulais dire la 1.0).
A+ chris
On 12 juin, 16:49, chris <cbon...@sra.fr> wrote:
Salut,
il y a aussi sqlObject, réputé plus "facil" que sqlAlchemy.
Pour ma part je suis habitué à l'ORM de Django qui répond parfait ement
à mes modestes besoins (en termes de compexité de schéma et requ ête,
mais pas de performance ni de volume).
Au fait, toi qui cherche un équivalent à RoR, Django
(djangoproject.com) est à mon avis bien supérieur à différents
niveaux.
Mais comme l'évangélisme n'est pas ma tasse de thé, je te laisse
découvrir la bête ...
... après ça, reviens poser des questions sur Django quand tu veux,
j'y répondrais de mon mieux.
Olive.
J'ai decouvert django j'ai un petit peut testé pour voir la bete
c'est bien mais j'ai pas compris certaine choses
Par exemple : le coté admin => c'est génial mais moi je veux
la même chose coté utilisateur et je comprends pas
Je ne vois pas ce qui t'en empêche!
mais il est vrai que cela sera plus facile avec la 1.0 imminente
qui permettra de personnaliser pus facilement l'interface d'admin
grâce au
nouveau système de gestion de formulaire déjà présent dans la 0.96.
la plupart des tutoriels explique comment developper des templates mais
c'est pas genial
L'idée est d'encourager l'écriture des règles business dans le fichier
views.py ou de définir de nouveaux "template tags" de manière à
affranchir le web designer du code.
C'est pour cela que le système template semble limité,
mais rien ne t'empêche d'adopter un autre systèmede template et
mélanger code et présentation àla PHP.
Bon comme je suis pas pressé j'attends un peu la maturité
Le produit est déjà très mature il ne faut ce fier au numéro de
version, d'autres seraient déjà en 9.6 avec la même maturité.
Mais il est vrai que l'on y verra encore plus claire avec 10.0 (euh...
non je voulais dire la 1.0).
il y a aussi sqlObject, réputé plus "facil" que sqlAlchemy.
Pour ma part je suis habitué à l'ORM de Django qui répond parfait ement à mes modestes besoins (en termes de compexité de schéma et requ ête, mais pas de performance ni de volume).
Au fait, toi qui cherche un équivalent à RoR, Django (djangoproject.com) est à mon avis bien supérieur à différents niveaux.
Mais comme l'évangélisme n'est pas ma tasse de thé, je te laisse découvrir la bête ... ... après ça, reviens poser des questions sur Django quand tu veux, j'y répondrais de mon mieux.
Olive.
J'ai decouvert django j'ai un petit peut testé pour voir la bete c'est bien mais j'ai pas compris certaine choses Par exemple : le coté admin => c'est génial mais moi je veux la même chose coté utilisateur et je comprends pas
Je ne vois pas ce qui t'en empêche! mais il est vrai que cela sera plus facile avec la 1.0 imminente qui permettra de personnaliser pus facilement l'interface d'admin grâce au nouveau système de gestion de formulaire déjà présent dans la 0.96.
la plupart des tutoriels explique comment developper des templates mais c'est pas genial
L'idée est d'encourager l'écriture des règles business dans le fichier views.py ou de définir de nouveaux "template tags" de manière à affranchir le web designer du code. C'est pour cela que le système template semble limité, mais rien ne t'empêche d'adopter un autre systèmede template et mélanger code et présentation àla PHP.
Bon comme je suis pas pressé j'attends un peu la maturité
Le produit est déjà très mature il ne faut ce fier au numéro de version, d'autres seraient déjà en 9.6 avec la même maturité.
Mais il est vrai que l'on y verra encore plus claire avec 10.0 (euh... non je voulais dire la 1.0).
A+ chris
MCI, Shadok Gouroudoudou
Perso, j'adore CherryPy. Mais, bon, la cible est plus spécifique.
-- @-salutations
Michel Claveau
Perso, j'adore CherryPy.
Mais, bon, la cible est plus spécifique.
Perso, j'adore CherryPy. Mais, bon, la cible est plus spécifique.
-- @-salutations
Michel Claveau
MCI, Shadok Gouroudoudou
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.
D'une manière générale, je trouve que ces enveloppes de SQL n'apportent rien, tout en limitant les possibilités.
Mais, il est vrai que je n'ai jeté que des regards succincts, car je n'ai rien trouvé de bien attirant.
Dans une autre direction, voici un truc que j'utilise quotidiennement. Ce n'est pas du SQL, ce n'est pas accessible par Python (mais ça peut utiliser Python) :
ui.attach(ctable) q=Query
OPTIONS: LIVE ORDER: g1.DB->"groupe 1"
g1.db | Check |
EndQuery if not q.executeQBE(ui) then errorshow() return endif
Ce code, en Object-PAL, va effectuer la requête, en prenant tous les champs, triés sur le champ "groupe 1". Mais, en plus, le résultat va être affiché dans un objet visuel "cadre-table", dans la fiche courante, et directement utilisable. Et, grâce à l'option "LIVE", si l'utilisateur modifie des valeurs, elles seront directement répercutées dans la base de données, sans code supplémentaire. En plus, ça fonctionne en réseau, avec un verrouillage pessimiste.
Le jour où il y aura un truc aussi simple en Python, j'adopterai...
-- @-salutations
Michel Claveau
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.
D'une manière générale, je trouve que ces enveloppes de SQL n'apportent
rien, tout en limitant les possibilités.
Mais, il est vrai que je n'ai jeté que des regards succincts, car je
n'ai rien trouvé de bien attirant.
Dans une autre direction, voici un truc que j'utilise quotidiennement.
Ce n'est pas du SQL, ce n'est pas accessible par Python (mais ça peut
utiliser Python) :
ui.attach(ctable)
q=Query
OPTIONS: LIVE
ORDER: g1.DB->"groupe 1"
g1.db |
Check |
EndQuery
if not q.executeQBE(ui) then
errorshow()
return
endif
Ce code, en Object-PAL, va effectuer la requête, en prenant tous les
champs, triés sur le champ "groupe 1".
Mais, en plus, le résultat va être affiché dans un objet visuel
"cadre-table", dans la fiche courante, et directement utilisable. Et,
grâce à l'option "LIVE", si l'utilisateur modifie des valeurs, elles
seront directement répercutées dans la base de données, sans code
supplémentaire. En plus, ça fonctionne en réseau, avec un verrouillage
pessimiste.
Le jour où il y aura un truc aussi simple en Python, j'adopterai...
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.
D'une manière générale, je trouve que ces enveloppes de SQL n'apportent rien, tout en limitant les possibilités.
Mais, il est vrai que je n'ai jeté que des regards succincts, car je n'ai rien trouvé de bien attirant.
Dans une autre direction, voici un truc que j'utilise quotidiennement. Ce n'est pas du SQL, ce n'est pas accessible par Python (mais ça peut utiliser Python) :
ui.attach(ctable) q=Query
OPTIONS: LIVE ORDER: g1.DB->"groupe 1"
g1.db | Check |
EndQuery if not q.executeQBE(ui) then errorshow() return endif
Ce code, en Object-PAL, va effectuer la requête, en prenant tous les champs, triés sur le champ "groupe 1". Mais, en plus, le résultat va être affiché dans un objet visuel "cadre-table", dans la fiche courante, et directement utilisable. Et, grâce à l'option "LIVE", si l'utilisateur modifie des valeurs, elles seront directement répercutées dans la base de données, sans code supplémentaire. En plus, ça fonctionne en réseau, avec un verrouillage pessimiste.
Le jour où il y aura un truc aussi simple en Python, j'adopterai...
-- @-salutations
Michel Claveau
MCI, Shadok Gouroudoudou
Oups ! J'avais mal lu.
Le code devrait plutôt être :
ui.attach(ctable) q=Query
OPTIONS: LIVE ORDER: g1.DB->"nom"
g1.db | nom | Check | "groupe 1" |
EndQuery if not q.executeQBE(ui) then errorshow() return endif
-- @-salutations
Michel Claveau
Oups !
J'avais mal lu.
Le code devrait plutôt être :
ui.attach(ctable)
q=Query
OPTIONS: LIVE
ORDER: g1.DB->"nom"
g1.db | nom |
Check | "groupe 1" |
EndQuery
if not q.executeQBE(ui) then
errorshow()
return
endif
EndQuery if not q.executeQBE(ui) then errorshow() return endif
-- @-salutations
Michel Claveau
Bruno Desthuilliers
On 13 juin, 11:26, Bruno Desthuilliers <bruno. wrote: (snip)
Au fait, toi qui cherche un équivalent à RoR, Django (djangoproject.com) est à mon avis bien supérieur à différents niveaux. Heu... Tu as réellement développé quelque chose (je veux dire, de
non-trivial) avec Rails ?
Non, javoue m'être rangé à l'avis général (snip)
Donc ce n'est pas "à *ton* avis" ?-)
Et forcément, l'avis de ceux qui sont passés de Rails à un autre framework est légèrement biaisé - il faudrait aussi connaître l'avis de ceux qui sont passés de XXX à rails, de ceux qui sont passés de Django à XXX, etc...
Django partage avec Rails l'inconvénient d'être un monolithe. En dehors
Quand tu dis monolithe, moi j'entend : "piles incluses" (battery included),
Ce qui n'est pas la même chose...
Personnellement, j'aime bien avoir le choix des composants que j'utilise - d'où mon intérêt pour Pylons. le qualificatif "battery included" s'applique mieux AMHA à Pylons - il y a tout le nécessaire par défaut, mais tu peux remplacer/ajouter/supprimer selon tes goûts et besoins. En ce qui concerne Rails et Django (et Turbogears dans une certaine mesure), les piles sont peut-être incluses, mais pour les remplacer, c'est un autre problème - il aurait peut-être fallu ne pas les mouler dans le bloc !-)
de ça - et bien que Django soit un très bon produit dans son genre -, j'avoue ne pas voir où est la "supériorité".
Allons, allons Bruno ! et Python alors ?
Le fait qu'un framework utilise Python n'est pas suffisant pour le rendre 'supérieur'.
Accessoirement, même si je préfère Python à Ruby sur certains points, Ruby est un excellent langage - c'est surtout l'implémentation qui ne tient pas (encore) la route.
Mais aussi Lighty, Apache avec mod_python ou wsgi,
Pylons est *basé* sur wsgi - ce n'est pas un ajout de dernière minute.
l'interface d'admin dynamique,
Qui a peu de chances de correspondre aux vrais besoins dès qu'on sort du trivial, et nécessite de polluer le modèle avec des considérations totalement orthogonales. Je préfère l'approche 'scaffolding' de Rails sur ce point.
la qualité de la doc
C'est certainement le point fort de Django.
et de la communauté
On peut en dire autant de Turbogears et Pylons.
On 13 juin, 11:26, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.com> wrote:
(snip)
Au fait, toi qui cherche un équivalent à RoR, Django
(djangoproject.com) est à mon avis bien supérieur à différents
niveaux.
Heu... Tu as réellement développé quelque chose (je veux dire, de
non-trivial) avec Rails ?
Non, javoue m'être rangé à l'avis général
(snip)
Donc ce n'est pas "à *ton* avis" ?-)
Et forcément, l'avis de ceux qui sont passés de Rails à un autre
framework est légèrement biaisé - il faudrait aussi connaître l'avis de
ceux qui sont passés de XXX à rails, de ceux qui sont passés de Django à
XXX, etc...
Django partage avec Rails l'inconvénient d'être un monolithe. En dehors
Quand tu dis monolithe, moi j'entend : "piles incluses" (battery
included),
Ce qui n'est pas la même chose...
Personnellement, j'aime bien avoir le choix des composants que j'utilise
- d'où mon intérêt pour Pylons. le qualificatif "battery included"
s'applique mieux AMHA à Pylons - il y a tout le nécessaire par défaut,
mais tu peux remplacer/ajouter/supprimer selon tes goûts et besoins. En
ce qui concerne Rails et Django (et Turbogears dans une certaine
mesure), les piles sont peut-être incluses, mais pour les remplacer,
c'est un autre problème - il aurait peut-être fallu ne pas les mouler
dans le bloc !-)
de ça - et bien que Django soit un très bon produit dans son genre -,
j'avoue ne pas voir où est la "supériorité".
Allons, allons Bruno ! et Python alors ?
Le fait qu'un framework utilise Python n'est pas suffisant pour le
rendre 'supérieur'.
Accessoirement, même si je préfère Python à Ruby sur certains points,
Ruby est un excellent langage - c'est surtout l'implémentation qui ne
tient pas (encore) la route.
Mais aussi Lighty, Apache avec mod_python ou wsgi,
Pylons est *basé* sur wsgi - ce n'est pas un ajout de dernière minute.
l'interface d'admin dynamique,
Qui a peu de chances de correspondre aux vrais besoins dès qu'on sort du
trivial, et nécessite de polluer le modèle avec des considérations
totalement orthogonales. Je préfère l'approche 'scaffolding' de Rails
sur ce point.
On 13 juin, 11:26, Bruno Desthuilliers <bruno. wrote: (snip)
Au fait, toi qui cherche un équivalent à RoR, Django (djangoproject.com) est à mon avis bien supérieur à différents niveaux. Heu... Tu as réellement développé quelque chose (je veux dire, de
non-trivial) avec Rails ?
Non, javoue m'être rangé à l'avis général (snip)
Donc ce n'est pas "à *ton* avis" ?-)
Et forcément, l'avis de ceux qui sont passés de Rails à un autre framework est légèrement biaisé - il faudrait aussi connaître l'avis de ceux qui sont passés de XXX à rails, de ceux qui sont passés de Django à XXX, etc...
Django partage avec Rails l'inconvénient d'être un monolithe. En dehors
Quand tu dis monolithe, moi j'entend : "piles incluses" (battery included),
Ce qui n'est pas la même chose...
Personnellement, j'aime bien avoir le choix des composants que j'utilise - d'où mon intérêt pour Pylons. le qualificatif "battery included" s'applique mieux AMHA à Pylons - il y a tout le nécessaire par défaut, mais tu peux remplacer/ajouter/supprimer selon tes goûts et besoins. En ce qui concerne Rails et Django (et Turbogears dans une certaine mesure), les piles sont peut-être incluses, mais pour les remplacer, c'est un autre problème - il aurait peut-être fallu ne pas les mouler dans le bloc !-)
de ça - et bien que Django soit un très bon produit dans son genre -, j'avoue ne pas voir où est la "supériorité".
Allons, allons Bruno ! et Python alors ?
Le fait qu'un framework utilise Python n'est pas suffisant pour le rendre 'supérieur'.
Accessoirement, même si je préfère Python à Ruby sur certains points, Ruby est un excellent langage - c'est surtout l'implémentation qui ne tient pas (encore) la route.
Mais aussi Lighty, Apache avec mod_python ou wsgi,
Pylons est *basé* sur wsgi - ce n'est pas un ajout de dernière minute.
l'interface d'admin dynamique,
Qui a peu de chances de correspondre aux vrais besoins dès qu'on sort du trivial, et nécessite de polluer le modèle avec des considérations totalement orthogonales. Je préfère l'approche 'scaffolding' de Rails sur ce point.
la qualité de la doc
C'est certainement le point fort de Django.
et de la communauté
On peut en dire autant de Turbogears et Pylons.
olive
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 ...
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).
Le jour ou un projet me semblera trop compliqué à réaliser avec Django alors j'évaluerais les autres.
Bonne soirée,
Olive.
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 ...
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).
Le jour ou un projet me semblera trop compliqué à réaliser avec Django
alors j'évaluerais les autres.
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 ...
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).
Le jour ou un projet me semblera trop compliqué à réaliser avec Django alors j'évaluerais les autres.
Bonne soirée,
Olive.
Laurent Pointal
MCI, Shadok Gouroudoudou wrote:
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.
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...
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.
Laurent.
MCI, Shadok Gouroudoudou wrote:
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.
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...
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.
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.
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...
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.
Laurent.
Laurent Pointal
MCI, Shadok Gouroudoudou wrote: ...
Ce code, en Object-PAL, va effectuer la requête, en prenant tous les champs, triés sur le champ "groupe 1". Mais, en plus, le résultat va être affiché dans un objet visuel "cadre-table", dans la fiche courante, et directement utilisable. Et, grâce à l'option "LIVE", si l'utilisateur modifie des valeurs, elles seront directement répercutées dans la base de données, sans code supplémentaire. En plus, ça fonctionne en réseau, avec un verrouillage pessimiste.
Le jour où il y aura un truc aussi simple en Python, j'adopterai...
Peut-être dans DaboDev ? (pour le moment je l'ai beaucoup vu sur clp par rapport à l'interface graphique, mais le but semble plus large, GUI+liens DB pour des applis)...
MCI, Shadok Gouroudoudou wrote:
...
Ce code, en Object-PAL, va effectuer la requête, en prenant tous les
champs, triés sur le champ "groupe 1".
Mais, en plus, le résultat va être affiché dans un objet visuel
"cadre-table", dans la fiche courante, et directement utilisable. Et,
grâce à l'option "LIVE", si l'utilisateur modifie des valeurs, elles
seront directement répercutées dans la base de données, sans code
supplémentaire. En plus, ça fonctionne en réseau, avec un verrouillage
pessimiste.
Le jour où il y aura un truc aussi simple en Python, j'adopterai...
Peut-être dans DaboDev ? (pour le moment je l'ai beaucoup vu sur clp par
rapport à l'interface graphique, mais le but semble plus large, GUI+liens
DB pour des applis)...
Ce code, en Object-PAL, va effectuer la requête, en prenant tous les champs, triés sur le champ "groupe 1". Mais, en plus, le résultat va être affiché dans un objet visuel "cadre-table", dans la fiche courante, et directement utilisable. Et, grâce à l'option "LIVE", si l'utilisateur modifie des valeurs, elles seront directement répercutées dans la base de données, sans code supplémentaire. En plus, ça fonctionne en réseau, avec un verrouillage pessimiste.
Le jour où il y aura un truc aussi simple en Python, j'adopterai...
Peut-être dans DaboDev ? (pour le moment je l'ai beaucoup vu sur clp par rapport à l'interface graphique, mais le but semble plus large, GUI+liens DB pour des applis)...
