Tout est dans le titre : je cherche un retour d'exp=E9rience sur les
frameworks de d=E9veloppement d'applis web. Je dois dire que je
privil=E9gie l'efficacit=E9 et compte =E9viter les frameworks =E0 la J2EE
qui me filent des mots de t=EAte rien qu'=E0 lire les fichiers de
configuration :o)
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Zope ;) Il y a beaucoup d'applications qui tournent en Zope 2 et quelques unes en Zope 3 qui est encore assez jeune, mais très prometteur.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les
frameworks de développement d'applis web. Je dois dire que je
privilégie l'efficacité et compte éviter les frameworks à la J2EE
qui me filent des mots de tête rien qu'à lire les fichiers de
configuration :o)
Zope ;)
Il y a beaucoup d'applications qui tournent en Zope 2 et quelques unes
en Zope 3 qui est encore assez jeune, mais très prometteur.
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Zope ;) Il y a beaucoup d'applications qui tournent en Zope 2 et quelques unes en Zope 3 qui est encore assez jeune, mais très prometteur.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Hervé Cauwelier
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Zope ;) Il y a beaucoup d'applications qui tournent en Zope 2 et quelques unes en Zope 3 qui est encore assez jeune, mais très prometteur.
T'as bien lu ce à quoi tu réponds ? :-)
-- Hervé Cauwelier http://www.vendredi.net/
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les
frameworks de développement d'applis web. Je dois dire que je
privilégie l'efficacité et compte éviter les frameworks à la J2EE
qui me filent des mots de tête rien qu'à lire les fichiers de
configuration :o)
Zope ;)
Il y a beaucoup d'applications qui tournent en Zope 2 et quelques unes
en Zope 3 qui est encore assez jeune, mais très prometteur.
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Zope ;) Il y a beaucoup d'applications qui tournent en Zope 2 et quelques unes en Zope 3 qui est encore assez jeune, mais très prometteur.
T'as bien lu ce à quoi tu réponds ? :-)
-- Hervé Cauwelier http://www.vendredi.net/
Encolpe Degoute
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Zope ;) Il y a beaucoup d'applications qui tournent en Zope 2 et quelques unes en Zope 3 qui est encore assez jeune, mais très prometteur.
T'as bien lu ce à quoi tu réponds ? :-)
Oui, mais j'étais un peu à la bourre avant de prendre le train de 7h25. Puis, le fichier de conf est simple dans Zope. O:) C'est le reste qui est complexe.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les
frameworks de développement d'applis web. Je dois dire que je
privilégie l'efficacité et compte éviter les frameworks à la J2EE
qui me filent des mots de tête rien qu'à lire les fichiers de
configuration :o)
Zope ;)
Il y a beaucoup d'applications qui tournent en Zope 2 et quelques unes
en Zope 3 qui est encore assez jeune, mais très prometteur.
T'as bien lu ce à quoi tu réponds ? :-)
Oui, mais j'étais un peu à la bourre avant de prendre le train de 7h25.
Puis, le fichier de conf est simple dans Zope. O:)
C'est le reste qui est complexe.
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Zope ;) Il y a beaucoup d'applications qui tournent en Zope 2 et quelques unes en Zope 3 qui est encore assez jeune, mais très prometteur.
T'as bien lu ce à quoi tu réponds ? :-)
Oui, mais j'étais un peu à la bourre avant de prendre le train de 7h25. Puis, le fichier de conf est simple dans Zope. O:) C'est le reste qui est complexe.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
bruno at modulix
casa wrote:
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Ca dépend pour quel type d'appli... et quel type de déploiement.
Côté frameworks MVC, plutôt orientés CRUD/SGBDR, tu a Django, Turbogears et Subway, et Pylon. * Django est basé sur mod_python et pgsql, et possède son propre ORM et son propre système de template. Personnellement, je le trouve un poil monolithique, mais ça semble être en train de s'arranger.
* Turbogears et Subway - dont il est question qu'ils fusionnent - sont en fait des "assemblages" : tous les deux se basent sur CherryPy (serveur applicatif HTTP Python) et SQLObject (orm). Côté templates, Turbogears utilise principalement Kid (il peut en accepter d'autre, notamment Cheetah, mais l'intégration est moins poussée), et Subway utilise Cheetah. Je pense que Turbogears est promis à un bel avenir, mais c'est un projet encore tout jeune et l'API reste très instable.
* Pylon est basé sur Myghty, Paste et SQLObject. Là aussi, c'est un projet très jeune, donc...
Côté 'serveur d'application', tu a Zope, CherryPy et Myghty. * Zope est un outil très puissant et remarquable sur bien des points, mais c'est un univers en lui-même, et l'apprentissage n'a rien d'évident. Zope 2.x est une solution fiable et éprouvée, mais avec une API tentaculaire et hélas trop mal documentée. Vu tes pré-requis concernant les fichiers de conf, je ne te recommande pas Zope 3.x...
* CherryPy est une solution très pythonesque, certainement beaucoup plus simple à prendre en main que Zope, mais peut-être pas d'aussi haut niveau.
* Myghty - un port de HTML:Mason avec quelques ajouts - est à la fois un système de template et un framework applicatif. Il permet d'utiliser soit un modèle de type 'Server page' (PHP, ASP, JSP etc) - mais en plus propre et construit que PHP !-) - soit un modèle MVC. Un de ses intérêts majeurs est qu'il peut être déployer de multiples façons (mod_python, CGI, FCGI, WSGI etc). Par contre, c'est de plus bas niveau que des solutions comme Zope, Django ou Turbogears. NB : il y a dans la doc un exemple d'appli MVC basé sur l'orm SLQAlchemy (très prometteur).
Mon expérience perso est surtout avec Zope2, qui est un outil remarquable mais avec une courbe d'apprentissage très raide, et qui s'avère souvent surdimensionné par rapport aux besoins courants de nos clients. On a aussi une paire d'appli développées avec Django - qui s'avère être un assez bon outil, mais pas toujours très souple. J'investigue également Myghty, dont j'apprécie la souplesse tant en matière d'architecture que de déploiement.
Il y a bien sûr pas mal d'autres solutions que je n'ai pas évalué (Twisted/nevow, Webware, Karrigel, Snakelets, Quixote, Albatross, etc, etc...). En fait, le problème avec les solutions de développement web en Python, c'est surtout qu'il y en a beaucoup, et la plupart de bonne qualité, il est donc difficile de faire son choix...
HTH
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
casa wrote:
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les
frameworks de développement d'applis web. Je dois dire que je
privilégie l'efficacité et compte éviter les frameworks à la J2EE
qui me filent des mots de tête rien qu'à lire les fichiers de
configuration :o)
Ca dépend pour quel type d'appli... et quel type de déploiement.
Côté frameworks MVC, plutôt orientés CRUD/SGBDR, tu a Django, Turbogears
et Subway, et Pylon.
* Django est basé sur mod_python et pgsql, et possède son propre ORM et
son propre système de template. Personnellement, je le trouve un poil
monolithique, mais ça semble être en train de s'arranger.
* Turbogears et Subway - dont il est question qu'ils fusionnent - sont
en fait des "assemblages" : tous les deux se basent sur CherryPy
(serveur applicatif HTTP Python) et SQLObject (orm). Côté templates,
Turbogears utilise principalement Kid (il peut en accepter d'autre,
notamment Cheetah, mais l'intégration est moins poussée), et Subway
utilise Cheetah. Je pense que Turbogears est promis à un bel avenir,
mais c'est un projet encore tout jeune et l'API reste très instable.
* Pylon est basé sur Myghty, Paste et SQLObject. Là aussi, c'est un
projet très jeune, donc...
Côté 'serveur d'application', tu a Zope, CherryPy et Myghty.
* Zope est un outil très puissant et remarquable sur bien des points,
mais c'est un univers en lui-même, et l'apprentissage n'a rien
d'évident. Zope 2.x est une solution fiable et éprouvée, mais avec une
API tentaculaire et hélas trop mal documentée. Vu tes pré-requis
concernant les fichiers de conf, je ne te recommande pas Zope 3.x...
* CherryPy est une solution très pythonesque, certainement beaucoup plus
simple à prendre en main que Zope, mais peut-être pas d'aussi haut niveau.
* Myghty - un port de HTML:Mason avec quelques ajouts - est à la fois un
système de template et un framework applicatif. Il permet d'utiliser
soit un modèle de type 'Server page' (PHP, ASP, JSP etc) - mais en plus
propre et construit que PHP !-) - soit un modèle MVC. Un de ses intérêts
majeurs est qu'il peut être déployer de multiples façons (mod_python,
CGI, FCGI, WSGI etc). Par contre, c'est de plus bas niveau que des
solutions comme Zope, Django ou Turbogears. NB : il y a dans la doc un
exemple d'appli MVC basé sur l'orm SLQAlchemy (très prometteur).
Mon expérience perso est surtout avec Zope2, qui est un outil
remarquable mais avec une courbe d'apprentissage très raide, et qui
s'avère souvent surdimensionné par rapport aux besoins courants de nos
clients. On a aussi une paire d'appli développées avec Django - qui
s'avère être un assez bon outil, mais pas toujours très souple.
J'investigue également Myghty, dont j'apprécie la souplesse tant en
matière d'architecture que de déploiement.
Il y a bien sûr pas mal d'autres solutions que je n'ai pas évalué
(Twisted/nevow, Webware, Karrigel, Snakelets, Quixote, Albatross, etc,
etc...). En fait, le problème avec les solutions de développement web en
Python, c'est surtout qu'il y en a beaucoup, et la plupart de bonne
qualité, il est donc difficile de faire son choix...
HTH
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Ca dépend pour quel type d'appli... et quel type de déploiement.
Côté frameworks MVC, plutôt orientés CRUD/SGBDR, tu a Django, Turbogears et Subway, et Pylon. * Django est basé sur mod_python et pgsql, et possède son propre ORM et son propre système de template. Personnellement, je le trouve un poil monolithique, mais ça semble être en train de s'arranger.
* Turbogears et Subway - dont il est question qu'ils fusionnent - sont en fait des "assemblages" : tous les deux se basent sur CherryPy (serveur applicatif HTTP Python) et SQLObject (orm). Côté templates, Turbogears utilise principalement Kid (il peut en accepter d'autre, notamment Cheetah, mais l'intégration est moins poussée), et Subway utilise Cheetah. Je pense que Turbogears est promis à un bel avenir, mais c'est un projet encore tout jeune et l'API reste très instable.
* Pylon est basé sur Myghty, Paste et SQLObject. Là aussi, c'est un projet très jeune, donc...
Côté 'serveur d'application', tu a Zope, CherryPy et Myghty. * Zope est un outil très puissant et remarquable sur bien des points, mais c'est un univers en lui-même, et l'apprentissage n'a rien d'évident. Zope 2.x est une solution fiable et éprouvée, mais avec une API tentaculaire et hélas trop mal documentée. Vu tes pré-requis concernant les fichiers de conf, je ne te recommande pas Zope 3.x...
* CherryPy est une solution très pythonesque, certainement beaucoup plus simple à prendre en main que Zope, mais peut-être pas d'aussi haut niveau.
* Myghty - un port de HTML:Mason avec quelques ajouts - est à la fois un système de template et un framework applicatif. Il permet d'utiliser soit un modèle de type 'Server page' (PHP, ASP, JSP etc) - mais en plus propre et construit que PHP !-) - soit un modèle MVC. Un de ses intérêts majeurs est qu'il peut être déployer de multiples façons (mod_python, CGI, FCGI, WSGI etc). Par contre, c'est de plus bas niveau que des solutions comme Zope, Django ou Turbogears. NB : il y a dans la doc un exemple d'appli MVC basé sur l'orm SLQAlchemy (très prometteur).
Mon expérience perso est surtout avec Zope2, qui est un outil remarquable mais avec une courbe d'apprentissage très raide, et qui s'avère souvent surdimensionné par rapport aux besoins courants de nos clients. On a aussi une paire d'appli développées avec Django - qui s'avère être un assez bon outil, mais pas toujours très souple. J'investigue également Myghty, dont j'apprécie la souplesse tant en matière d'architecture que de déploiement.
Il y a bien sûr pas mal d'autres solutions que je n'ai pas évalué (Twisted/nevow, Webware, Karrigel, Snakelets, Quixote, Albatross, etc, etc...). En fait, le problème avec les solutions de développement web en Python, c'est surtout qu'il y en a beaucoup, et la plupart de bonne qualité, il est donc difficile de faire son choix...
HTH
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
bruno at modulix
Encolpe Degoute wrote:
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Zope ;) Il y a beaucoup d'applications qui tournent en Zope 2
Yep, mais point de vue apprentissage, c'est pas ce qu'on a fait de plus simple... (bien que ça en vaille le coup, rien que pour ce truc de ouf qu'est l'acquisition).
et quelques unes en Zope 3 qui est encore assez jeune, mais très prometteur.
Encolpe, le monsieur il a dit "pas de fichier de conf à la J2EE" !-)
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Encolpe Degoute wrote:
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les
frameworks de développement d'applis web. Je dois dire que je
privilégie l'efficacité et compte éviter les frameworks à la J2EE
qui me filent des mots de tête rien qu'à lire les fichiers de
configuration :o)
Zope ;)
Il y a beaucoup d'applications qui tournent en Zope 2
Yep, mais point de vue apprentissage, c'est pas ce qu'on a fait de plus
simple... (bien que ça en vaille le coup, rien que pour ce truc de ouf
qu'est l'acquisition).
et quelques unes
en Zope 3 qui est encore assez jeune, mais très prometteur.
Encolpe, le monsieur il a dit "pas de fichier de conf à la J2EE" !-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web. Je dois dire que je privilégie l'efficacité et compte éviter les frameworks à la J2EE qui me filent des mots de tête rien qu'à lire les fichiers de configuration :o)
Zope ;) Il y a beaucoup d'applications qui tournent en Zope 2
Yep, mais point de vue apprentissage, c'est pas ce qu'on a fait de plus simple... (bien que ça en vaille le coup, rien que pour ce truc de ouf qu'est l'acquisition).
et quelques unes en Zope 3 qui est encore assez jeune, mais très prometteur.
Encolpe, le monsieur il a dit "pas de fichier de conf à la J2EE" !-)
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Hervé Cauwelier
Yep, mais point de vue apprentissage, c'est pas ce qu'on a fait de plus simple... (bien que ça en vaille le coup, rien que pour ce truc de ouf qu'est l'acquisition).
Ouais, quand t'as une méthode qui peut s'appliquer n'importe où, à n'importe quoi, que tu dois débugger, que tu dois assurer la sécurité dans des cas normalement impossibles, c'est sûr, c'est à devenir ouf.
Indice : L'acquisition implicite a été abandonnée dans Zope 3.
Bon, en même temps, ils ont mis des tartines de XML dans Zope 3, donc on ne peut pas dire qu'ils n'ont fait que des bons choix.
-- Hervé Cauwelier http://www.oursours.net/
Yep, mais point de vue apprentissage, c'est pas ce qu'on a fait de plus
simple... (bien que ça en vaille le coup, rien que pour ce truc de ouf
qu'est l'acquisition).
Ouais, quand t'as une méthode qui peut s'appliquer n'importe où, à
n'importe quoi, que tu dois débugger, que tu dois assurer la sécurité
dans des cas normalement impossibles, c'est sûr, c'est à devenir ouf.
Indice : L'acquisition implicite a été abandonnée dans Zope 3.
Bon, en même temps, ils ont mis des tartines de XML dans Zope 3, donc on
ne peut pas dire qu'ils n'ont fait que des bons choix.
Yep, mais point de vue apprentissage, c'est pas ce qu'on a fait de plus simple... (bien que ça en vaille le coup, rien que pour ce truc de ouf qu'est l'acquisition).
Ouais, quand t'as une méthode qui peut s'appliquer n'importe où, à n'importe quoi, que tu dois débugger, que tu dois assurer la sécurité dans des cas normalement impossibles, c'est sûr, c'est à devenir ouf.
Indice : L'acquisition implicite a été abandonnée dans Zope 3.
Bon, en même temps, ils ont mis des tartines de XML dans Zope 3, donc on ne peut pas dire qu'ils n'ont fait que des bons choix.
-- Hervé Cauwelier http://www.oursours.net/
bruno at modulix
Hervé Cauwelier wrote:
Salut Hervé
Yep, mais point de vue apprentissage, c'est pas ce qu'on a fait de plus simple... (bien que ça en vaille le coup, rien que pour ce truc de ouf qu'est l'acquisition).
Ouais, quand t'as une méthode qui peut s'appliquer n'importe où, à n'importe quoi, que tu dois débugger, que tu dois assurer la sécurité dans des cas normalement impossibles, c'est sûr, c'est à devenir ouf.
Et c'est pas rien de le dire...
Je n'ai pas dit que l'acquisition *implicite* était une bonne chose. Par contre, le *concept* d'acquisition est AMHA tout simplement génial, et Zope est la seule application que je connaisse qui en fasse usage.
Indice : L'acquisition implicite a été abandonnée dans Zope 3.
Heureusement...
Bon, en même temps, ils ont mis des tartines de XML dans Zope 3,
Malheureusement :(
donc on ne peut pas dire qu'ils n'ont fait que des bons choix.
Non, c'est clair (enfin, AMHA et toute cette sorte de choses...).
Dans un cas comme dans l'autre (je veux dire, Zope 2.x et Zope 3.x), il y a beaucoup de très bonnes idées (l'acquisition dans Zope2, le système interface/adapter - merci PEAK - dans Zope3), qui méritent le détour. Le problème maintenant est surtout de trouver un moyen de mettre ces concepts en oeuvre d'une façon plus pythonesque...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Hervé Cauwelier wrote:
Salut Hervé
Yep, mais point de vue apprentissage, c'est pas ce qu'on a fait de plus
simple... (bien que ça en vaille le coup, rien que pour ce truc de ouf
qu'est l'acquisition).
Ouais, quand t'as une méthode qui peut s'appliquer n'importe où, à
n'importe quoi, que tu dois débugger, que tu dois assurer la sécurité
dans des cas normalement impossibles, c'est sûr, c'est à devenir ouf.
Et c'est pas rien de le dire...
Je n'ai pas dit que l'acquisition *implicite* était une bonne chose. Par
contre, le *concept* d'acquisition est AMHA tout simplement génial, et
Zope est la seule application que je connaisse qui en fasse usage.
Indice : L'acquisition implicite a été abandonnée dans Zope 3.
Heureusement...
Bon, en même temps, ils ont mis des tartines de XML dans Zope 3,
Malheureusement :(
donc on
ne peut pas dire qu'ils n'ont fait que des bons choix.
Non, c'est clair (enfin, AMHA et toute cette sorte de choses...).
Dans un cas comme dans l'autre (je veux dire, Zope 2.x et Zope 3.x), il
y a beaucoup de très bonnes idées (l'acquisition dans Zope2, le système
interface/adapter - merci PEAK - dans Zope3), qui méritent le détour. Le
problème maintenant est surtout de trouver un moyen de mettre ces
concepts en oeuvre d'une façon plus pythonesque...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Yep, mais point de vue apprentissage, c'est pas ce qu'on a fait de plus simple... (bien que ça en vaille le coup, rien que pour ce truc de ouf qu'est l'acquisition).
Ouais, quand t'as une méthode qui peut s'appliquer n'importe où, à n'importe quoi, que tu dois débugger, que tu dois assurer la sécurité dans des cas normalement impossibles, c'est sûr, c'est à devenir ouf.
Et c'est pas rien de le dire...
Je n'ai pas dit que l'acquisition *implicite* était une bonne chose. Par contre, le *concept* d'acquisition est AMHA tout simplement génial, et Zope est la seule application que je connaisse qui en fasse usage.
Indice : L'acquisition implicite a été abandonnée dans Zope 3.
Heureusement...
Bon, en même temps, ils ont mis des tartines de XML dans Zope 3,
Malheureusement :(
donc on ne peut pas dire qu'ils n'ont fait que des bons choix.
Non, c'est clair (enfin, AMHA et toute cette sorte de choses...).
Dans un cas comme dans l'autre (je veux dire, Zope 2.x et Zope 3.x), il y a beaucoup de très bonnes idées (l'acquisition dans Zope2, le système interface/adapter - merci PEAK - dans Zope3), qui méritent le détour. Le problème maintenant est surtout de trouver un moyen de mettre ces concepts en oeuvre d'une façon plus pythonesque...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
F. Petitjean
casa wrote:
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web.
Ca dépend pour quel type d'appli... et quel type de déploiement.
Côté frameworks MVC, plutôt orientés CRUD/SGBDR, tu a Django, Turbogears et Subway, et Pylon. snip
Côté 'serveur d'application', tu a Zope, CherryPy et Myghty. snip
Mon expérience perso est surtout avec Zope2, qui est un outil remarquable mais avec une courbe d'apprentissage très raide, et qui snip
Il y a bien sûr pas mal d'autres solutions que je n'ai pas évalué (Twisted/nevow, Webware, Karrigel, Snakelets, Quixote, Albatross, etc, etc...). En fait, le problème avec les solutions de développement web en Python, c'est surtout qu'il y en a beaucoup, et la plupart de bonne qualité, il est donc difficile de faire son choix...
HTH
Je trouve l'ensemble de ce message remarquable, à la fois structuré,
clair et détaillé. Serait-il possible de l'intégrer dans un Wiki ?
casa wrote:
Bonjour,
Tout est dans le titre : je cherche un retour d'expérience sur les
frameworks de développement d'applis web.
Ca dépend pour quel type d'appli... et quel type de déploiement.
Côté frameworks MVC, plutôt orientés CRUD/SGBDR, tu a Django, Turbogears
et Subway, et Pylon.
snip
Côté 'serveur d'application', tu a Zope, CherryPy et Myghty.
snip
Mon expérience perso est surtout avec Zope2, qui est un outil
remarquable mais avec une courbe d'apprentissage très raide, et qui
snip
Il y a bien sûr pas mal d'autres solutions que je n'ai pas évalué
(Twisted/nevow, Webware, Karrigel, Snakelets, Quixote, Albatross, etc,
etc...). En fait, le problème avec les solutions de développement web en
Python, c'est surtout qu'il y en a beaucoup, et la plupart de bonne
qualité, il est donc difficile de faire son choix...
HTH
Je trouve l'ensemble de ce message remarquable, à la fois structuré,
clair et détaillé.
Serait-il possible de l'intégrer dans un Wiki ?
Tout est dans le titre : je cherche un retour d'expérience sur les frameworks de développement d'applis web.
Ca dépend pour quel type d'appli... et quel type de déploiement.
Côté frameworks MVC, plutôt orientés CRUD/SGBDR, tu a Django, Turbogears et Subway, et Pylon. snip
Côté 'serveur d'application', tu a Zope, CherryPy et Myghty. snip
Mon expérience perso est surtout avec Zope2, qui est un outil remarquable mais avec une courbe d'apprentissage très raide, et qui snip
Il y a bien sûr pas mal d'autres solutions que je n'ai pas évalué (Twisted/nevow, Webware, Karrigel, Snakelets, Quixote, Albatross, etc, etc...). En fait, le problème avec les solutions de développement web en Python, c'est surtout qu'il y en a beaucoup, et la plupart de bonne qualité, il est donc difficile de faire son choix...
HTH
Je trouve l'ensemble de ce message remarquable, à la fois structuré,
clair et détaillé. Serait-il possible de l'intégrer dans un Wiki ?
Jacques Pronchery
Bonjour,
Avec Cherrypy comment fait-on pour afficher une image ?
Merci
Jacques.
Bonjour,
Avec Cherrypy comment fait-on pour afficher une image ?
Avec Cherrypy comment fait-on pour afficher une image ?
Merci
Jacques.
R12y
bruno at modulix :
Mon expérience perso est surtout avec Zope2, qui est un outil remarquable mais avec une courbe d'apprentissage très raide
Tiens, j'ai toujours cru que quand on schematisait la courbe d'apprentissage, on mettait le temps en abcsisse ("x", pas "y"). Si on met le temps en abcsisse, la courbe est presque horizontale (tout le contraire de raide).
Non?
-- My Debian/apt repo: My Fedora/yum Repo: http://www.locataire-serveur.info/sections/liens/fedora-core-yum
bruno at modulix :
Mon expérience perso est surtout avec Zope2, qui est un outil
remarquable mais avec une courbe d'apprentissage très raide
Tiens, j'ai toujours cru que quand on schematisait la courbe
d'apprentissage, on mettait le temps en abcsisse ("x", pas "y").
Si on met le temps en abcsisse, la courbe est presque horizontale (tout le
contraire de raide).
Non?
--
My Debian/apt repo:
My Fedora/yum Repo:
http://www.locataire-serveur.info/sections/liens/fedora-core-yum
Mon expérience perso est surtout avec Zope2, qui est un outil remarquable mais avec une courbe d'apprentissage très raide
Tiens, j'ai toujours cru que quand on schematisait la courbe d'apprentissage, on mettait le temps en abcsisse ("x", pas "y"). Si on met le temps en abcsisse, la courbe est presque horizontale (tout le contraire de raide).
Non?
-- My Debian/apt repo: My Fedora/yum Repo: http://www.locataire-serveur.info/sections/liens/fedora-core-yum
