Django-fr

Forum

  • Accueil
  • » Django-fr
  • » Django :Utilisation d'API SOAP en lieu et place de la database ?

#1 30-10-2008 01:11:37

Thomas Chiroux
Membre
Inscription : 11-08-2010
Messages : 9

Django :Utilisation d'API SOAP en lieu et place de la database ?

Hello,

Sur un projet en cours, je souhaite utiliser django pour créer des
applications de configuration d'outils existants.
Ces outils se servent d'une base et de serveurs d'application (appelons là
"back-end"), dans laquelle il y a toutes les données nécessaires et dont les
interfaces de lecture et modifications sont publiées via les serveurs
d'applications en SOAP [désolé, c'est une appli existante..]

Le schéma est donc actuellement le suivant (schéma classique dans nos
grandes entreprises)

Client <===http/ajax===> [Front END] <====== SOAP ======> [Serveur
application] <===jdbc===> [base back-end]
                      (php aujourd'hui)


et je voudrais ajouter un ou des serveurs 'back-office' (qui vont servir à
des utilisateurs internes à configurer les différentes applications gérées
et par conséquent changer ce que le client va voir.
Cela donne le schéma suivant :

Client <===http/ajax===> [Front END] <====== SOAP ======> [Serveur
application] <===jdbc===> [base back-end]
                                                                  /\
                                                                  ||
                                                                  ||
                                                                  ||
                                                                 SOAP
                                                                  ||
                                                                  ||
                                                                  ||
                                                                  \/
                                                            [Back-Office
(django)]

et ce back-office je voudrais qu'on le fasse en django.

Le 'problème' est que dans ce cas, il n'y a pas besoin de base de donnée
locale pour django (meme la gestion des users utilisant le back-office est
dans la base de donnée du back-end)

Une de mes idées est de faire réécrire un backend (au sens django) de base
de donnée pour SOAP. Ainsi, dans les models, on définit simplement les
différents API Soap : pour chacune, une class héritée de models est définie.
Ensuite on continue comme d'habitude.
Pour gérer les users et/ou l'admin autogénérée, c'est peut etre un peu plus
compliqué, a voir.

est-ce que vous savez si cela a déjà été fait quelque part ?
A moins que vous ayez une autre idée ? (en dehors de jetter l'existant en
java :-) ?)

Merci,

Thomas.

Hors ligne

#2 30-10-2008 01:30:03

David Larlet
Membre
Inscription : 11-08-2010
Messages : 102

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

Le 30 oct. 08 à 01:11, Thomas Chiroux a écrit :

> Hello,
Hello,
>
>
> Sur un projet en cours, je souhaite utiliser django pour créer des 
> applications de configuration d'outils existants.
> Ces outils se servent d'une base et de serveurs d'application 
> (appelons là "back-end"), dans laquelle il y a toutes les données 
> nécessaires et dont les interfaces de lecture et modifications sont 
> publiées via les serveurs d'applications en SOAP [désolé, c'est une 
> appli existante..]
[...]
> est-ce que vous savez si cela a déjà été fait quelque part ?
> A moins que vous ayez une autre idée ? (en dehors de jetter 
> l'existant en java :-) ?)

C'est marrant comme coïncidence car je me renseignais là-dessus 
aujourd'hui aussi, non pas pour taper sur du SOAP mais du REST. Je 
n'ai rien trouvé de pertinent malheureusement, il va falloir le coder 
et ça demande de toucher aux Models et Querysets (j'aimerais que le 
passage de l'un à l'autre ne s'effectue qu'en fonction d'un setting 
car c'est bien pratique de pouvoir tester sur une base locale dans un 
premier temps). Se pose aussi le problème des contribs/apps existantes 
qui ne vont pas hériter des bons models par défaut.

Beaucoup de boulot en perspective...

Bonne soirée,
David

Hors ligne

#3 30-10-2008 02:23:59

Benoit Chesneau
Membre
Inscription : 11-08-2010
Messages : 57

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

2008/10/30 David Larlet <larlet _AT_ gmail.com>:
>
> Le 30 oct. 08 à 01:11, Thomas Chiroux a écrit :
>
>> Hello,
>
> Hello,
>>
>>
>> Sur un projet en cours, je souhaite utiliser django pour créer des
>> applications de configuration d'outils existants.
>> Ces outils se servent d'une base et de serveurs d'application (appelons là
>> "back-end"), dans laquelle il y a toutes les données nécessaires et dont les
>> interfaces de lecture et modifications sont publiées via les serveurs
>> d'applications en SOAP [désolé, c'est une appli existante..]
>
> [...]
>>
>> est-ce que vous savez si cela a déjà été fait quelque part ?
>> A moins que vous ayez une autre idée ? (en dehors de jetter l'existant en
>> java :-) ?)
>
> C'est marrant comme coïncidence car je me renseignais là-dessus aujourd'hui
> aussi, non pas pour taper sur du SOAP mais du REST. Je n'ai rien trouvé de
> pertinent malheureusement, il va falloir le coder et ça demande de toucher
> aux Models et Querysets

Le backend REST pour accéder à du sql est finalement assez simple. Une
solution serait de passer les add/delete/update via les verbes http et
passer les arguments des querysets sous formes d'arguments http dans
l'uri ou dans le body http. Les reponses pourrait être sous format
json.

ex :

* filter(champ__exact="blah) ->
GET /ipserveur/db/base?action=filter&champ__exact=blah, ....

* get(champ__exact="blah") ->
GET /ipserveu/rdb/base?action=get&champ__exact=blah, ....

* model.save() ->
POST/PUT /ipserver/db/table body=objet sous forme json Si la fk est là
il s'agit d'un update sinon d'un create



* models.delete() ->
DELETE /ipserveur/db/table/fk

....


Le service Rest qui reçoit ces requêtes les transforme alors en sql.
Vu que les arguments reçus sont ceux des queryset il est relativement
aisé en reprenant le code de django de faire cette conversion.

Les modèles à mon avis n'ont pas besoin d'être retouchés sauf pour
choisir la destination d'un modèle (indiquer un range d'IP ou les
serveurs). Cela pourrait être fait via la class Meta du modele.

Pour écraser les querysets le backend d'Oracle donne une bonne idée.

(j'aimerais que le passage de l'un à l'autre ne
> s'effectue qu'en fonction d'un setting car c'est bien pratique de pouvoir
> tester sur une base locale dans un premier temps).

Amha si tu dois tester en local tu peux simplement utiliser une base sqlite..

> Se pose aussi le problème
> des contribs/apps existantes qui ne vont pas hériter des bons models par
> défaut.
>
Je ne comprend pas le souci ici. Tu as un exemple ?


> Beaucoup de boulot en perspective...
>

Si le projet est opensource  ça m'interesserai d'y participer....

- benoît

Hors ligne

#4 30-10-2008 02:40:39

Benoit Chesneau
Membre
Inscription : 11-08-2010
Messages : 57

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

2008/10/30 Benoit Chesneau <bchesneau _AT_ gmail.com>:
> ex :
>
> * filter(champ__exact="blah) ->
> GET /ipserveur/db/base?action=filter&champ__exact=blah, ....
>
> * get(champ__exact="blah") ->
> GET /ipserveu/rdb/base?action=get&champ__exact=blah, ....
>
> * model.save() ->
> POST/PUT /ipserver/db/table body=objet sous forme json Si la fk est là
> il s'agit d'un update sinon d'un create
>
>
>
> * models.delete() ->
> DELETE /ipserveur/db/table/fk
>
> ....

qqs ptites correction, par rapport à ce qui est ci-dessus, je pense
que même les args de get doivent être en json. Par ailleurs plutot que
action=, filter= est mieux. Cela donnerait :

/ipserveur/db/base?filter=[{ 'cham__exact' = 'blah']]

chaque dict correspond à un filer. les filters sont chainés dans la
liste.  On peut gérer les q pareillements.

- benoit

Hors ligne

#5 30-10-2008 02:58:06

David Larlet
Membre
Inscription : 11-08-2010
Messages : 102

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

Le 30 oct. 08 à 02:23, Benoit Chesneau a écrit :
>
> Le backend REST pour accéder à du sql est finalement assez simple. Une
> solution serait de passer les add/delete/update via les verbes http et
> passer les arguments des querysets sous formes d'arguments http dans
> l'uri ou dans le body http. Les reponses pourrait être sous format
> json.
>
Oui c'est ce que j'avais en tête.
>
> Le service Rest qui reçoit ces requêtes les transforme alors en sql.
> Vu que les arguments reçus sont ceux des queryset il est relativement
> aisé en reprenant le code de django de faire cette conversion.
>
> Les modèles à mon avis n'ont pas besoin d'être retouchés sauf pour
> choisir la destination d'un modèle (indiquer un range d'IP ou les
> serveurs). Cela pourrait être fait via la class Meta du modele.
Là où je voulais toucher aux modèles c'est pour mapper les réponses 
JSON et avoir des instances de modèles permettant d'utiliser Django de 
façon habituelle (notamment pour conserver l'interface d'admin).
>
>
> Pour écraser les querysets le backend d'Oracle donne une bonne idée.
Ok merci.
>
>
> (j'aimerais que le passage de l'un à l'autre ne
>> s'effectue qu'en fonction d'un setting car c'est bien pratique de 
>> pouvoir
>> tester sur une base locale dans un premier temps).
>
> Amha si tu dois tester en local tu peux simplement utiliser une base 
> sqlite..
Oui c'est ce que j'essayais d'expliquer, pouvoir développer en local 
sur du sqlite puis ensuite pouvoir passer sur l'architecture complète.
>
>
>> Se pose aussi le problème
>> des contribs/apps existantes qui ne vont pas hériter des bons 
>> models par
>> défaut.
>>
> Je ne comprend pas le souci ici. Tu as un exemple ?
C'est lié aux modèles, cf plus haut.
>
>
>> Beaucoup de boulot en perspective...
>>
>
> Si le projet est opensource  ça m'interesserai d'y participer....

Je vais voir, pas sûr que ce soit possible.

David

Hors ligne

#6 30-10-2008 08:56:28

Thomas Chiroux
Membre
Inscription : 11-08-2010
Messages : 9

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

J'avais également un truc comme ça en tete.
J'ai un peu plus de contraintes que David, les api soap étant - a priori -
(il faut voir si je peux les faire évoluer, cela doit etre possible aussi)
déjà définie.

De mon cote je ne vois aucune objection a passer cette partie du code en
open source. Ce qui m'inquiete plus c'est le manque de séniorité du
développeur qui va devoir faire ça, cela risque de ne pas etre évident pour
lui.

Je vous tiens au courant.

Thomas.

2008/10/30 David Larlet <larlet _AT_ gmail.com>

>
> Le 30 oct. 08 à 02:23, Benoit Chesneau a écrit :
>
>>
>> Le backend REST pour accéder à du sql est finalement assez simple. Une
>> solution serait de passer les add/delete/update via les verbes http et
>> passer les arguments des querysets sous formes d'arguments http dans
>> l'uri ou dans le body http. Les reponses pourrait être sous format
>> json.
>>
>>  Oui c'est ce que j'avais en tête.
>
>>
>> Le service Rest qui reçoit ces requêtes les transforme alors en sql.
>> Vu que les arguments reçus sont ceux des queryset il est relativement
>> aisé en reprenant le code de django de faire cette conversion.
>>
>> Les modèles à mon avis n'ont pas besoin d'être retouchés sauf pour
>> choisir la destination d'un modèle (indiquer un range d'IP ou les
>> serveurs). Cela pourrait être fait via la class Meta du modele.
>>
> Là où je voulais toucher aux modèles c'est pour mapper les réponses JSON et
> avoir des instances de modèles permettant d'utiliser Django de façon
> habituelle (notamment pour conserver l'interface d'admin).
>
>>
>>
>> Pour écraser les querysets le backend d'Oracle donne une bonne idée.
>>
> Ok merci.
>
>>
>>
>> (j'aimerais que le passage de l'un à l'autre ne
>>
>>> s'effectue qu'en fonction d'un setting car c'est bien pratique de pouvoir
>>> tester sur une base locale dans un premier temps).
>>>
>>
>> Amha si tu dois tester en local tu peux simplement utiliser une base
>> sqlite..
>>
> Oui c'est ce que j'essayais d'expliquer, pouvoir développer en local sur du
> sqlite puis ensuite pouvoir passer sur l'architecture complète.
>
>>
>>
>>  Se pose aussi le problème
>>> des contribs/apps existantes qui ne vont pas hériter des bons models par
>>> défaut.
>>>
>>>  Je ne comprend pas le souci ici. Tu as un exemple ?
>>
> C'est lié aux modèles, cf plus haut.
>
>>
>>
>>  Beaucoup de boulot en perspective...
>>>
>>>
>> Si le projet est opensource  ça m'interesserai d'y participer....
>>
>
> Je vais voir, pas sûr que ce soit possible.
>
> David
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>

Hors ligne

#7 30-10-2008 10:09:07

Benoit Chesneau
Membre
Inscription : 11-08-2010
Messages : 57

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

2008/10/30 David Larlet <larlet _AT_ gmail.com>:

>> Les modèles à mon avis n'ont pas besoin d'être retouchés sauf pour
>> choisir la destination d'un modèle (indiquer un range d'IP ou les
>> serveurs). Cela pourrait être fait via la class Meta du modele.
>
> Là où je voulais toucher aux modèles c'est pour mapper les réponses JSON et
> avoir des instances de modèles permettant d'utiliser Django de façon
> habituelle (notamment pour conserver l'interface d'admin).
>>

hum si la query renvoie la bonne réponse tu n'as pas forcemment besoin
de faire ça. Je voyais le process suivant :

query <->conversion rest <-> service web <-> sql

à part ça as tu jeté un oup d'oeuil à dbslayer ? :
http://code.nytimes.com/projects/dbslayer


ç'est ce qui amha se rapproche le plus de ce que tu souhaites faire.

- benoît

Hors ligne

#8 31-10-2008 22:21:46

spango
Membre
Inscription : 11-08-2010
Messages : 12

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

Thomas Chiroux a écrit :
> J'avais également un truc comme ça en tete.
> J'ai un peu plus de contraintes que David, les api soap étant - a
> priori - (il faut voir si je peux les faire évoluer, cela doit etre
> possible aussi) déjà définie.
>
> De mon cote je ne vois aucune objection a passer cette partie du code
> en open source.
Le problème que je vois, c'est que ça n'a aucun intérêt de passer ce
projet en opensource, si l'api soap est propriétaire et figée.
> Ce qui m'inquiete plus c'est le manque de séniorité du développeur qui
> va devoir faire ça, cela risque de ne pas etre évident pour lui.
Avec un développeur expérimenté, ce sera déjà très compliqué à mon avis;
sans, c'est casse-cou.
Il vaut mieux jeter Java, ou y a -t-il pas une solution peut être en
attaquant la base directement avec django (inspectdb).

@+,
Eric SIMORRE.
>
> Je vous tiens au courant.
>
> Thomas.
>
> 2008/10/30 David Larlet <larlet _AT_ gmail.com <mailto:larlet _AT_ gmail.com>>
>
>
>     Le 30 oct. 08 à 02:23, Benoit Chesneau a écrit :
>
>
>         Le backend REST pour accéder à du sql est finalement assez
>         simple. Une
>         solution serait de passer les add/delete/update via les verbes
>         http et
>         passer les arguments des querysets sous formes d'arguments
>         http dans
>         l'uri ou dans le body http. Les reponses pourrait être sous format
>         json.
>
>     Oui c'est ce que j'avais en tête.
>
>
>         Le service Rest qui reçoit ces requêtes les transforme alors
>         en sql.
>         Vu que les arguments reçus sont ceux des queryset il est
>         relativement
>         aisé en reprenant le code de django de faire cette conversion.
>
>         Les modèles à mon avis n'ont pas besoin d'être retouchés sauf pour
>         choisir la destination d'un modèle (indiquer un range d'IP ou les
>         serveurs). Cela pourrait être fait via la class Meta du modele.
>
>     Là où je voulais toucher aux modèles c'est pour mapper les
>     réponses JSON et avoir des instances de modèles permettant
>     d'utiliser Django de façon habituelle (notamment pour conserver
>     l'interface d'admin).
>
>
>
>         Pour écraser les querysets le backend d'Oracle donne une bonne
>         idée.
>
>     Ok merci.
>
>
>
>         (j'aimerais que le passage de l'un à l'autre ne
>
>             s'effectue qu'en fonction d'un setting car c'est bien
>             pratique de pouvoir
>             tester sur une base locale dans un premier temps).
>
>
>         Amha si tu dois tester en local tu peux simplement utiliser
>         une base sqlite..
>
>     Oui c'est ce que j'essayais d'expliquer, pouvoir développer en
>     local sur du sqlite puis ensuite pouvoir passer sur l'architecture
>     complète.
>
>
>
>             Se pose aussi le problème
>             des contribs/apps existantes qui ne vont pas hériter des
>             bons models par
>             défaut.
>
>         Je ne comprend pas le souci ici. Tu as un exemple ?
>
>     C'est lié aux modèles, cf plus haut.
>
>
>
>             Beaucoup de boulot en perspective...
>
>
>         Si le projet est opensource  ça m'interesserai d'y participer....
>
>
>     Je vais voir, pas sûr que ce soit possible.
>
>     David
>
>
>     _______________________________________________
>     django mailing list
>     django _AT_ lists.afpy.org <mailto:django _AT_ lists.afpy.org>
>     http://lists.afpy.org/mailman/listinfo/django
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django

Hors ligne

#9 02-11-2008 11:49:34

Benoit Chesneau
Membre
Inscription : 11-08-2010
Messages : 57

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

2008/10/31 spango <spango _AT_ free.fr>:
> Thomas Chiroux a écrit :
>
> J'avais également un truc comme ça en tete.
> J'ai un peu plus de contraintes que David, les api soap étant - a priori -
> (il faut voir si je peux les faire évoluer, cela doit etre possible aussi)
> déjà définie.
>
> De mon cote je ne vois aucune objection a passer cette partie du code en
> open source.
>
> Le problème que je vois, c'est que ça n'a aucun intérêt de passer ce projet
> en opensource, si l'api soap est propriétaire et figée.
>
> Ce qui m'inquiete plus c'est le manque de séniorité du développeur qui va
> devoir faire ça, cela risque de ne pas etre évident pour lui.
>
> Avec un développeur expérimenté, ce sera déjà très compliqué à mon avis;
> sans, c'est casse-cou.
> Il vaut mieux jeter Java, ou y a -t-il pas une solution peut être en
> attaquant la base directement avec django (inspectdb).


Tout le monde sait en effet que java c'est pour les nuls....

Que vient faire inspectdb ici ? là où un dev opensource pourrait être
efficace ce serait pour offrir pourquoi pas un backent qui à travers
des règles customisables envoie ce que l'on veut via http soap/rest ou
autre.


- benoît

Hors ligne

#10 02-11-2008 23:05:07

spango
Membre
Inscription : 11-08-2010
Messages : 12

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

Benoit Chesneau a écrit :
> 2008/10/31 spango <spango _AT_ free.fr>:
>   
>> Thomas Chiroux a écrit :
>>
>> J'avais également un truc comme ça en tete.
>> J'ai un peu plus de contraintes que David, les api soap étant - a priori -
>> (il faut voir si je peux les faire évoluer, cela doit etre possible aussi)
>> déjà définie.
>>
>> De mon cote je ne vois aucune objection a passer cette partie du code en
>> open source.
>>
>> Le problème que je vois, c'est que ça n'a aucun intérêt de passer ce projet
>> en opensource, si l'api soap est propriétaire et figée.
>>
>> Ce qui m'inquiete plus c'est le manque de séniorité du développeur qui va
>> devoir faire ça, cela risque de ne pas etre évident pour lui.
>>
>> Avec un développeur expérimenté, ce sera déjà très compliqué à mon avis;
>> sans, c'est casse-cou.
>> Il vaut mieux jeter Java, ou y a -t-il pas une solution peut être en
>> attaquant la base directement avec django (inspectdb).
>>     
>
>
> Tout le monde sait en effet que java c'est pour les nuls....
>   
Ce que je veux dire, c'est qu'on peut envisager peut-être (je connais
pas du tout le contexte) d'abandonner java pour du tout django.
> Que vient faire inspectdb ici ?
on a une base de donnée existante et si on veut l'attaquer avec django,
la commande inspectdb est faite pour ça.
> là où un dev opensource pourrait être
> efficace ce serait pour offrir pourquoi pas un backent qui à travers
> des règles customisables envoie ce que l'on veut via http soap/rest ou
> autre
>   
il me semble que faire un backend vers une source de données soap peut
déjà être complexe à faire; si en plus on veut faire du générique
réutilisable/paramétrable, on est pas rendu; et puis, j'ai déjà fait du
soap avec python, j'en est de mauvais souvenirs.
Bon de toute façon, en théorie, tout est faisable; après faut voir de
combien de temps et de ressources développeurs on dispose, et quel est
le budget.
@+
>
> - benoît
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
>
>

Hors ligne

#11 03-11-2008 07:23:06

Rémy HUBSCHER
Membre
Inscription : 11-08-2010
Messages : 161

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

Oui mais au final faire les choses bien sa paye beaucoup plus que 
faire les choses mal.
Dans le deuxième cas, il te faudra tout recommencer la prochaine fois.
Dans le premier, il te suffit juste de réfléchir à la meilleure 
manière de faire et non à la plus simple.

Après si tu travailles sur un base existante tu ne pourras pas 
utiliser la simplicité des models avec Django donc ça perd de son 
intérêt.

++
Natim

Le 2 nov. 08 à 23:05, spango a écrit :

> Benoit Chesneau a écrit :
>> 2008/10/31 spango <spango _AT_ free.fr>:
>>
>>> Thomas Chiroux a écrit :
>>>
>>> J'avais également un truc comme ça en tete.
>>> J'ai un peu plus de contraintes que David, les api soap étant - a 
>>> priori -
>>> (il faut voir si je peux les faire évoluer, cela doit etre 
>>> possible aussi)
>>> déjà définie.
>>>
>>> De mon cote je ne vois aucune objection a passer cette partie du 
>>> code en
>>> open source.
>>>
>>> Le problème que je vois, c'est que ça n'a aucun intérêt de passer 
>>> ce projet
>>> en opensource, si l'api soap est propriétaire et figée.
>>>
>>> Ce qui m'inquiete plus c'est le manque de séniorité du développeur 
>>> qui va
>>> devoir faire ça, cela risque de ne pas etre évident pour lui.
>>>
>>> Avec un développeur expérimenté, ce sera déjà très compliqué à mon 
>>> avis;
>>> sans, c'est casse-cou.
>>> Il vaut mieux jeter Java, ou y a -t-il pas une solution peut être en
>>> attaquant la base directement avec django (inspectdb).
>>>
>>
>>
>> Tout le monde sait en effet que java c'est pour les nuls....
>>
> Ce que je veux dire, c'est qu'on peut envisager peut-être (je 
> connais pas du tout le contexte) d'abandonner java pour du tout 
> django.
>> Que vient faire inspectdb ici ?
> on a une base de donnée existante et si on veut l'attaquer avec 
> django, la commande inspectdb est faite pour ça.
>> là où un dev opensource pourrait être
>> efficace ce serait pour offrir pourquoi pas un backent qui à travers
>> des règles customisables envoie ce que l'on veut via http soap/rest 
>> ou
>> autre
>>
> il me semble que faire un backend vers une source de données soap 
> peut déjà être complexe à faire; si en plus on veut faire du 
> générique réutilisable/paramétrable, on est pas rendu; et puis, j'ai 
> déjà fait du soap avec python, j'en est de mauvais souvenirs.
> Bon de toute façon, en théorie, tout est faisable; après faut voir 
> de combien de temps et de ressources développeurs on dispose, et 
> quel est le budget.
> @+
>>
>> - benoît
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>>
>>
>>
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django

Hors ligne

#12 03-11-2008 20:56:47

spango
Membre
Inscription : 11-08-2010
Messages : 12

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

Rémy Hubscher a écrit :
> Oui mais au final faire les choses bien sa paye beaucoup plus que
> faire les choses mal.
Là, il faut aussi apprendre la modestie et l'humilité: "faire comme je
le sens" n'est pas la même chose que "faire bien" :-)

Et encore ce que tu dis à l'air d'une évidence, mais dans un contexte
commercial ça ne l'est pas du tout: un client préferera souvent une
solution qui marche dans 15 jours, plutôt qu'un truc génial qui marchera
dans 6 mois ... peut-être.
> Dans le deuxième cas, il te faudra tout recommencer la prochaine fois.
Là encore dans un contexte commercial, ça peut permettre de vendre un
second projet (et oui, on vit pas que d'amour et d'eau fraiche)
> Dans le premier, il te suffit juste de réfléchir à la meilleure
> manière de faire et non à la plus simple.
oui "juste la meilleure façon": c'est juste ce qu'il y a de plus
difficile dans notre métier; et le choix n'est que rarement aussi
binaire; aucune solution n'est simple, mais il y a peut-être une
possible et l'autre pas.
>
> Après si tu travailles sur un base existante tu ne pourras pas
> utiliser la simplicité des models avec Django donc ça perd de son intérêt.
je comprend pas ce que tu veux dire.

@+
>
>
> ++
> Natim
>
> Le 2 nov. 08 à 23:05, spango a écrit :
>
>> Benoit Chesneau a écrit :
>>> 2008/10/31 spango <spango _AT_ free.fr>:
>>>
>>>> Thomas Chiroux a écrit :
>>>>
>>>> J'avais également un truc comme ça en tete.
>>>> J'ai un peu plus de contraintes que David, les api soap étant - a
>>>> priori -
>>>> (il faut voir si je peux les faire évoluer, cela doit etre possible
>>>> aussi)
>>>> déjà définie.
>>>>
>>>> De mon cote je ne vois aucune objection a passer cette partie du
>>>> code en
>>>> open source.
>>>>
>>>> Le problème que je vois, c'est que ça n'a aucun intérêt de passer
>>>> ce projet
>>>> en opensource, si l'api soap est propriétaire et figée.
>>>>
>>>> Ce qui m'inquiete plus c'est le manque de séniorité du développeur
>>>> qui va
>>>> devoir faire ça, cela risque de ne pas etre évident pour lui.
>>>>
>>>> Avec un développeur expérimenté, ce sera déjà très compliqué à mon
>>>> avis;
>>>> sans, c'est casse-cou.
>>>> Il vaut mieux jeter Java, ou y a -t-il pas une solution peut être en
>>>> attaquant la base directement avec django (inspectdb).
>>>>
>>>
>>>
>>> Tout le monde sait en effet que java c'est pour les nuls....
>>>
>> Ce que je veux dire, c'est qu'on peut envisager peut-être (je connais
>> pas du tout le contexte) d'abandonner java pour du tout django.
>>> Que vient faire inspectdb ici ?
>> on a une base de donnée existante et si on veut l'attaquer avec
>> django, la commande inspectdb est faite pour ça.
>>> là où un dev opensource pourrait être
>>> efficace ce serait pour offrir pourquoi pas un backent qui à travers
>>> des règles customisables envoie ce que l'on veut via http soap/rest ou
>>> autre
>>>
>> il me semble que faire un backend vers une source de données soap
>> peut déjà être complexe à faire; si en plus on veut faire du
>> générique réutilisable/paramétrable, on est pas rendu; et puis, j'ai
>> déjà fait du soap avec python, j'en est de mauvais souvenirs.
>> Bon de toute façon, en théorie, tout est faisable; après faut voir de
>> combien de temps et de ressources développeurs on dispose, et quel
>> est le budget.
>> @+
>>>
>>> - benoît
>>> _______________________________________________
>>> django mailing list
>>> django _AT_ lists.afpy.org
>>> http://lists.afpy.org/mailman/listinfo/django
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
>

Hors ligne

#13 03-11-2008 21:16:49

Rémy HUBSCHER
Membre
Inscription : 11-08-2010
Messages : 161

Re : Django :Utilisation d'API SOAP en lieu et place de la database ?

Salut,

Je me place dans un contexte Libre. Je sais bien que Commercial est 
différent de libre, et que SOAP est aussi différent de libre. Mais 
Django est libre donc le fait de rajouter la gestion de SOAP serait 
libre.
Après rajouter le support de SOAP à Django ça ne va rien te rapporter 
si ce n'est de pouvoir faire tes projets avec Django.

Tu peux très bien vendre un second projet basé sur le premier. Dans ce 
cas ce que tu fais bien la première fois sera réinvesti.

C'est justement parce que faire comme je le sent est différent de 
faire bien qu'il faut un effort supplémentaire pour passer de l'un à 
l'autre.
C'est parce que l'on fait trop souvent des applications qui marche 
sous 15 jours plutôt qu'un truc génial qui prend plus de temps que 
l'on doit toujours tout recommencer.
Et c'est justement parce que Django n'est pas un truc qui marche sous 
15 jours qu'autant de gens veulent l'utiliser.

Python utilisé par un développeur agile te permet cependant de faire 
des trucs géniaux en 15 jours.

Dans ton cas d'utilisation de l'API SOAP, tu dis vouloir travailler 
sur une base existante.
Il y a peu de chance pour que la base existante aie la même structure 
que celle qu'attendent les models Django.

Tu ne pourras donc pas remplir cette table SOAP avec le système de 
models Django si tu compte utiliser une base existante.
Par conséquent, il est peu avantageux de développer un bakends pour 
SOAP si tu ne peux pas l'utiliser dans le cas qui t'intéresse.

@+

Natim

Le 3 nov. 08 à 20:56, spango a écrit :

> Rémy Hubscher a écrit :
>> Oui mais au final faire les choses bien sa paye beaucoup plus que 
>> faire les choses mal.
> Là, il faut aussi apprendre la modestie et l'humilité: "faire comme 
> je le sens" n'est pas la même chose que "faire bien" :-)
>
> Et encore ce que tu dis à l'air d'une évidence, mais dans un 
> contexte commercial ça ne l'est pas du tout: un client préferera 
> souvent une solution qui marche dans 15 jours, plutôt qu'un truc 
> génial qui marchera dans 6 mois ... peut-être.
>> Dans le deuxième cas, il te faudra tout recommencer la prochaine 
>> fois.
> Là encore dans un contexte commercial, ça peut permettre de vendre 
> un second projet (et oui, on vit pas que d'amour et d'eau fraiche)
>> Dans le premier, il te suffit juste de réfléchir à la meilleure 
>> manière de faire et non à la plus simple.
> oui "juste la meilleure façon": c'est juste ce qu'il y a de plus 
> difficile dans notre métier; et le choix n'est que rarement aussi 
> binaire; aucune solution n'est simple, mais il y a peut-être une 
> possible et l'autre pas.
>>
>> Après si tu travailles sur un base existante tu ne pourras pas 
>> utiliser la simplicité des models avec Django donc ça perd de son 
>> intérêt.
> je comprend pas ce que tu veux dire.
>
> @+
>>
>>
>> ++
>> Natim
>>
>> Le 2 nov. 08 à 23:05, spango a écrit :
>>
>>> Benoit Chesneau a écrit :
>>>> 2008/10/31 spango <spango _AT_ free.fr>:
>>>>
>>>>> Thomas Chiroux a écrit :
>>>>>
>>>>> J'avais également un truc comme ça en tete.
>>>>> J'ai un peu plus de contraintes que David, les api soap étant - 
>>>>> a priori -
>>>>> (il faut voir si je peux les faire évoluer, cela doit etre 
>>>>> possible aussi)
>>>>> déjà définie.
>>>>>
>>>>> De mon cote je ne vois aucune objection a passer cette partie du 
>>>>> code en
>>>>> open source.
>>>>>
>>>>> Le problème que je vois, c'est que ça n'a aucun intérêt de 
>>>>> passer ce projet
>>>>> en opensource, si l'api soap est propriétaire et figée.
>>>>>
>>>>> Ce qui m'inquiete plus c'est le manque de séniorité du 
>>>>> développeur qui va
>>>>> devoir faire ça, cela risque de ne pas etre évident pour lui.
>>>>>
>>>>> Avec un développeur expérimenté, ce sera déjà très compliqué à 
>>>>> mon avis;
>>>>> sans, c'est casse-cou.
>>>>> Il vaut mieux jeter Java, ou y a -t-il pas une solution peut 
>>>>> être en
>>>>> attaquant la base directement avec django (inspectdb).
>>>>>
>>>>
>>>>
>>>> Tout le monde sait en effet que java c'est pour les nuls....
>>>>
>>> Ce que je veux dire, c'est qu'on peut envisager peut-être (je 
>>> connais pas du tout le contexte) d'abandonner java pour du tout 
>>> django.
>>>> Que vient faire inspectdb ici ?
>>> on a une base de donnée existante et si on veut l'attaquer avec 
>>> django, la commande inspectdb est faite pour ça.
>>>> là où un dev opensource pourrait être
>>>> efficace ce serait pour offrir pourquoi pas un backent qui à 
>>>> travers
>>>> des règles customisables envoie ce que l'on veut via http soap/
>>>> rest ou
>>>> autre
>>>>
>>> il me semble que faire un backend vers une source de données soap 
>>> peut déjà être complexe à faire; si en plus on veut faire du 
>>> générique réutilisable/paramétrable, on est pas rendu; et puis, 
>>> j'ai déjà fait du soap avec python, j'en est de mauvais souvenirs.
>>> Bon de toute façon, en théorie, tout est faisable; après faut voir 
>>> de combien de temps et de ressources développeurs on dispose, et 
>>> quel est le budget.
>>> @+
>>>>
>>>> - benoît
>>>> _______________________________________________
>>>> django mailing list
>>>> django _AT_ lists.afpy.org
>>>> http://lists.afpy.org/mailman/listinfo/django
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> django mailing list
>>> django _AT_ lists.afpy.org
>>> http://lists.afpy.org/mailman/listinfo/django
>>
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>>
>>
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django

Hors ligne

  • Accueil
  • » Django-fr
  • » Django :Utilisation d'API SOAP en lieu et place de la database ?

Pied de page des forums