j'ai un projet d'application utilisant une base de données SQL. Je
souhaite faire l'interface utilisateur sur une base de python. Je
souhaite également que l'application puisse fonctionner sous win, mac et
si possible linux ce qui me semblait plaider en faveur de wxpython.
Mon problème c'est que je me perds dans la jungle des frameworks et
autres possibilités de développement pour python en matière d'interface
graphique et de bdd.
J'ai défini un schéma de base sur un PostgreSQL aussi je souhaiterais
pouvoir m'interfacer avec ce moteur mais j'ai un peu joué avec gadfly
pour découvrir et ça pourrait aussi convenir pour un proto, je n'utilise
plus les fonctions avancées de base que j'avais envisagé (héritage de
table).
J'ajoute que je souhaite faire en priorité une application locale, mais
j'envisage aussi de faire une application web. Soit une version
simplifiée de consultation de la base ou pourquoi pas une version web de
l'appli, je ne sais pas les possibilités qui peuvent exister.
Ce soir je viens juste de tomber sur Dabo (http://dabodev.com/about) qui
est un framework (encore un) de dev 3 tiers qui s'appuie sur wxpython.
Intéressant mais encore incomplet.
Existe-t-il un répertoire des frameworks existant sur ce thème ? Avez
vous des conseils sur la question ? Comment faites-vous pour savoir ce
qui existe dans le domaine, vous essayez toutes les nouveautés ? Et
comment miser le bon cheval qui va évoluer et pas sur un des nombreux
projets qui démarre puis s'éteint ?
Mais j'ai fais des choix très particuliers, car l'interconnexion entre html/javvascript/css et python est faite par de multiples liens COM (typiquement, pour un écran, j'ai entre une vingtaine et un millier de liens).
Mais du coup, tu ne développes pas vraiment ton application comme un serveur web ?
Dans ma tête, c'est plutôt écrire une appli web tout ce qu'il y a de plus classique, cad ne développer que le serveur, avec les techniques habituelles qui suppose que le client est un navigateur (HTTP, HTML, javascript, css), et au final, "packager" mon serveur avec un client pour en faire une application.
Tout ce qui m'intéresse, c'est d'avoir le serveur et le client "dans la même fenêtre", avec un mécanisme qui fait un peu de nettoyage et tue le serveur quand tu quittes l'appli.
Mais on peut aller plus loin, par exemple, un bouton imprimer qui comprendrait qu'il faut utiliser le media print de ta css.
A priori (mais je parle peut-être dans le vide, je n'ai jamais développé d'application autonome), je pense à deux solutions :
- utiliser wx.lib.iewin dont je viens d'entendre parler sur comp.lang.python. wxPython lancerait le serveur dans un thread, et n'aurait qu'une seule fenêtre qui interface ie.
- sinon, plus portable, utiliser XUL. En utilisant les filtres Cherrypy, par exemple, il doit être facile de pouvoir envoyer au choix les headers HTTP si tu es dans une utilisation Web classique, ou d'enchâsser ton HTML dans le markup XUL qui va bien si tu es dans un contexte 'application'. Je dis peut-être n'importe quoi, je connais très peu XUL.
Bon dimanche !
Olivier
Hello,
Mais j'ai fais des choix très particuliers, car l'interconnexion entre
html/javvascript/css et python est faite par de multiples liens COM
(typiquement, pour un écran, j'ai entre une vingtaine et un millier de
liens).
Mais du coup, tu ne développes pas vraiment ton application comme un
serveur web ?
Dans ma tête, c'est plutôt écrire une appli web tout ce qu'il y a de
plus classique, cad ne développer que le serveur, avec les techniques
habituelles qui suppose que le client est un navigateur (HTTP, HTML,
javascript, css), et au final, "packager" mon serveur avec un client
pour en faire une application.
Tout ce qui m'intéresse, c'est d'avoir le serveur et le client "dans la
même fenêtre", avec un mécanisme qui fait un peu de nettoyage et tue le
serveur quand tu quittes l'appli.
Mais on peut aller plus loin, par exemple, un bouton imprimer qui
comprendrait qu'il faut utiliser le media print de ta css.
A priori (mais je parle peut-être dans le vide, je n'ai jamais développé
d'application autonome), je pense à deux solutions :
- utiliser wx.lib.iewin dont je viens d'entendre parler sur
comp.lang.python. wxPython lancerait le serveur dans un thread, et
n'aurait qu'une seule fenêtre qui interface ie.
- sinon, plus portable, utiliser XUL. En utilisant les filtres Cherrypy,
par exemple, il doit être facile de pouvoir envoyer au choix les headers
HTTP si tu es dans une utilisation Web classique, ou d'enchâsser ton
HTML dans le markup XUL qui va bien si tu es dans un contexte
'application'. Je dis peut-être n'importe quoi, je connais très peu XUL.
Mais j'ai fais des choix très particuliers, car l'interconnexion entre html/javvascript/css et python est faite par de multiples liens COM (typiquement, pour un écran, j'ai entre une vingtaine et un millier de liens).
Mais du coup, tu ne développes pas vraiment ton application comme un serveur web ?
Dans ma tête, c'est plutôt écrire une appli web tout ce qu'il y a de plus classique, cad ne développer que le serveur, avec les techniques habituelles qui suppose que le client est un navigateur (HTTP, HTML, javascript, css), et au final, "packager" mon serveur avec un client pour en faire une application.
Tout ce qui m'intéresse, c'est d'avoir le serveur et le client "dans la même fenêtre", avec un mécanisme qui fait un peu de nettoyage et tue le serveur quand tu quittes l'appli.
Mais on peut aller plus loin, par exemple, un bouton imprimer qui comprendrait qu'il faut utiliser le media print de ta css.
A priori (mais je parle peut-être dans le vide, je n'ai jamais développé d'application autonome), je pense à deux solutions :
- utiliser wx.lib.iewin dont je viens d'entendre parler sur comp.lang.python. wxPython lancerait le serveur dans un thread, et n'aurait qu'une seule fenêtre qui interface ie.
- sinon, plus portable, utiliser XUL. En utilisant les filtres Cherrypy, par exemple, il doit être facile de pouvoir envoyer au choix les headers HTTP si tu es dans une utilisation Web classique, ou d'enchâsser ton HTML dans le markup XUL qui va bien si tu es dans un contexte 'application'. Je dis peut-être n'importe quoi, je connais très peu XUL.
Bon dimanche !
Olivier
Méta-MCI
Bonjour !
Mais du coup, tu ne développes pas vraiment ton application comme un serveur web ?
Exact. En pratique c'est un HTA (HTml-Application) qui est piloté par Python. Ou, si l'on préfère, c'est un serveur COM en Python, avec un browser comme GUI. La gestion des serveurs COM étant automatique, c'est plus simple. L'avantage, c'est que, une fois Python (+librairies) installé, il n'y a rien d'autre à installer/configurer (en dehors des applis proprement dites).
Mais, je n'utilise pas http (ni, donc, XML HTTP request). Ces protocoles sont trop limités pour mon usage, du point de vue canaux de communication. Avec COM, j'ai des liens directs vers des zones de la page du GUI. Par exemple, il est possible de lire/écrire le contenu d'un label, ou d'un champ, directement en Python.
En plus, c'est rapide : j'ai testé plusieurs milliers d'appels par seconde, sans problème.
Par contre, ce n'est pas utilisable via Internet ; ça n'a rien à voir avec le web. C'est une autre démarche.
sinon, plus portable, utiliser XUL
XUL n'est pas portable, car il ne fonctionne que dans l'environnement FireFox. De plus XulRunner ne sera vraiment utilisable qu'en 2007 (avec la version 1.9)
Bon dimanche !
De même.
MCI
Bonjour !
Mais du coup, tu ne développes pas vraiment ton application comme un
serveur web ?
Exact.
En pratique c'est un HTA (HTml-Application) qui est piloté par Python.
Ou, si l'on préfère, c'est un serveur COM en Python, avec un browser comme
GUI. La gestion des serveurs COM étant automatique, c'est plus simple.
L'avantage, c'est que, une fois Python (+librairies) installé, il n'y a rien
d'autre à installer/configurer (en dehors des applis proprement dites).
Mais, je n'utilise pas http (ni, donc, XML HTTP request). Ces protocoles
sont trop limités pour mon usage, du point de vue canaux de communication.
Avec COM, j'ai des liens directs vers des zones de la page du GUI. Par
exemple, il est possible de lire/écrire le contenu d'un label, ou d'un
champ, directement en Python.
En plus, c'est rapide : j'ai testé plusieurs milliers d'appels par seconde,
sans problème.
Par contre, ce n'est pas utilisable via Internet ; ça n'a rien à voir avec
le web. C'est une autre démarche.
sinon, plus portable, utiliser XUL
XUL n'est pas portable, car il ne fonctionne que dans l'environnement
FireFox.
De plus XulRunner ne sera vraiment utilisable qu'en 2007 (avec la version
1.9)
Mais du coup, tu ne développes pas vraiment ton application comme un serveur web ?
Exact. En pratique c'est un HTA (HTml-Application) qui est piloté par Python. Ou, si l'on préfère, c'est un serveur COM en Python, avec un browser comme GUI. La gestion des serveurs COM étant automatique, c'est plus simple. L'avantage, c'est que, une fois Python (+librairies) installé, il n'y a rien d'autre à installer/configurer (en dehors des applis proprement dites).
Mais, je n'utilise pas http (ni, donc, XML HTTP request). Ces protocoles sont trop limités pour mon usage, du point de vue canaux de communication. Avec COM, j'ai des liens directs vers des zones de la page du GUI. Par exemple, il est possible de lire/écrire le contenu d'un label, ou d'un champ, directement en Python.
En plus, c'est rapide : j'ai testé plusieurs milliers d'appels par seconde, sans problème.
Par contre, ce n'est pas utilisable via Internet ; ça n'a rien à voir avec le web. C'est une autre démarche.
sinon, plus portable, utiliser XUL
XUL n'est pas portable, car il ne fonctionne que dans l'environnement FireFox. De plus XulRunner ne sera vraiment utilisable qu'en 2007 (avec la version 1.9)
Bon dimanche !
De même.
MCI
Michel Claveau
Bonjour !
Ton commentaire sur Django est appétissant. Si tu avais une comparaison avec turbogears, ce serait parfait...
-- @-salutations
Michel Claveau
Bonjour !
Ton commentaire sur Django est appétissant.
Si tu avais une comparaison avec turbogears, ce serait parfait...
Ton commentaire sur Django est appétissant. Si tu avais une comparaison avec turbogears, ce serait parfait...
-- @-salutations
Michel Claveau
Eric Jacoboni
William Dode writes:
Je viens d'essayer django, je ne sais pas ce que ça donnera au final mais en tout cas pour prototyper c'est vraiment génial, on défini le modèle de la BDD en python et ensuite il cré automatiquement les tables (y compris les jointures !) dans postgresql (mysql ou sqlite) et les formulaires de saisie (avec recherche, filtre, jointure, gestion des droits...).
Oui, mais cela n'a pas grand chose avec voir avec un framework web, en fait. Ce que tu décris est un ORM et ça peut très bien s'utiliser à chaque fois qu'on a besoin d'un accès à une BD (moi, d'ailleurs, j'ai viré DBI et autres plaisanteries SQLiennes pour ne plus utiliser que ça quand j'ai besoin d'accéder à une BD).
Il en y en a deux sortes, correspondant à des situations différentes : ceux comme tu décris, qui créent les tables à partir des classes (pratique quand on part de rien) et ceux qui créent les classes à partir de tables existantes (pratique lorsqu'on a déjà une base).
Le côté attirant des frameworks comme RoR (et Django si j'ai bien compris) est surtout qu'il permettent de créer un squelette CRUD en trois coups de cuiller à pot. -- Eric Jacoboni, ne il y a 1455886924 secondes
William Dode <wilk-ml@flibuste.net> writes:
Je viens d'essayer django, je ne sais pas ce que ça donnera au final
mais en tout cas pour prototyper c'est vraiment génial, on défini le
modèle de la BDD en python et ensuite il cré automatiquement les tables
(y compris les jointures !) dans postgresql (mysql ou sqlite) et les
formulaires de saisie (avec recherche, filtre, jointure, gestion des
droits...).
Oui, mais cela n'a pas grand chose avec voir avec un framework web, en
fait. Ce que tu décris est un ORM et ça peut très bien s'utiliser à
chaque fois qu'on a besoin d'un accès à une BD (moi, d'ailleurs, j'ai
viré DBI et autres plaisanteries SQLiennes pour ne plus utiliser que
ça quand j'ai besoin d'accéder à une BD).
Il en y en a deux sortes, correspondant à des situations différentes :
ceux comme tu décris, qui créent les tables à partir des classes
(pratique quand on part de rien) et ceux qui créent les classes à
partir de tables existantes (pratique lorsqu'on a déjà une base).
Le côté attirant des frameworks comme RoR (et Django si j'ai bien
compris) est surtout qu'il permettent de créer un squelette CRUD en trois
coups de cuiller à pot.
--
Eric Jacoboni, ne il y a 1455886924 secondes
Je viens d'essayer django, je ne sais pas ce que ça donnera au final mais en tout cas pour prototyper c'est vraiment génial, on défini le modèle de la BDD en python et ensuite il cré automatiquement les tables (y compris les jointures !) dans postgresql (mysql ou sqlite) et les formulaires de saisie (avec recherche, filtre, jointure, gestion des droits...).
Oui, mais cela n'a pas grand chose avec voir avec un framework web, en fait. Ce que tu décris est un ORM et ça peut très bien s'utiliser à chaque fois qu'on a besoin d'un accès à une BD (moi, d'ailleurs, j'ai viré DBI et autres plaisanteries SQLiennes pour ne plus utiliser que ça quand j'ai besoin d'accéder à une BD).
Il en y en a deux sortes, correspondant à des situations différentes : ceux comme tu décris, qui créent les tables à partir des classes (pratique quand on part de rien) et ceux qui créent les classes à partir de tables existantes (pratique lorsqu'on a déjà une base).
Le côté attirant des frameworks comme RoR (et Django si j'ai bien compris) est surtout qu'il permettent de créer un squelette CRUD en trois coups de cuiller à pot. -- Eric Jacoboni, ne il y a 1455886924 secondes
pikatxu
On Sun, 09 Jul 2006 12:21:10 +0200, Michel Claveau wrote:
Bonjour !
Ton commentaire sur Django est appétissant. Si tu avais une comparaison avec turbogears, ce serait parfait...
+1 ça m'interresse aussi
On Sun, 09 Jul 2006 12:21:10 +0200, Michel Claveau wrote:
Bonjour !
Ton commentaire sur Django est appétissant.
Si tu avais une comparaison avec turbogears, ce serait parfait...
On Sun, 09 Jul 2006 12:21:10 +0200, Michel Claveau wrote:
Bonjour !
Ton commentaire sur Django est appétissant. Si tu avais une comparaison avec turbogears, ce serait parfait...
+1 ça m'interresse aussi
Franssoa
Quelle différence fais-tu entre la sortie du navigateur par le bouton quitter et la fermeture de la fenêtre ? ...
Un serveur web et une base de donnée (bon, pas Oracle, hein...) qui ne font rien ne devraient pas prendre beaucoup de ressources... J'avoue que je n'ai pas mesuré. C'est surtout de la consommation des
ressources mémoires dont j'ai peur (j'ai une petite config, alors...) Mais bon, je vais tester tout ça :-)
Franssoa
Quelle différence fais-tu entre la sortie du navigateur par le bouton
quitter et la fermeture de la fenêtre ?
...
Un serveur web et une base de donnée (bon, pas Oracle, hein...) qui ne
font rien ne devraient pas prendre beaucoup de ressources...
J'avoue que je n'ai pas mesuré. C'est surtout de la consommation des
ressources mémoires dont j'ai peur (j'ai une petite config, alors...)
Mais bon, je vais tester tout ça :-)
Quelle différence fais-tu entre la sortie du navigateur par le bouton quitter et la fermeture de la fenêtre ? ...
Un serveur web et une base de donnée (bon, pas Oracle, hein...) qui ne font rien ne devraient pas prendre beaucoup de ressources... J'avoue que je n'ai pas mesuré. C'est surtout de la consommation des
ressources mémoires dont j'ai peur (j'ai une petite config, alors...) Mais bon, je vais tester tout ça :-)
