Je trouve un peu dommage de mélanger les vues et les templates. Le principe des pages HTML remplies de TAGS invalides (au sens XML) avec des <% ce n'est pas très moderne et c'est le même principe que le php, asp, ou le DTML dans Zope2 qui a été abandonné dans Zope3.
Une vue ne doit pas nécessairement être une page web, c'est censé être une vision particulière d'un contenu (par ex un objet). Donc ça peut générer une sortie PDF, une vue par FTP ou par WEBDAV ou en HTML, et dans ce cas une vue doit _utiliser_ un template, mais pas être un template. Il faut limiter au maximum le code contenu dans les templates, car c'est le boulot de la vue.
Dans zope3 une vue peut aussi être juste un morceau de page (un viewlet), qui est intégré dans un gestionnaire de viewlet et qui peut (ou non) utiliser un template pour son rendu. Ca permet de faire des pages avec des boites et des contenus complètement variables et dépendants du contexte, de manière très souple et très intéressante.
C'est vraiment regrettable que la doc et la visibilté de zope3 soient si faibles car les principes utilisés sont vraiments intéressants (on en retrouve dans j2ee, mais pas forcément de la même façon, et sans la soupless de python) et c'est un framework qui est maintenant très stable et très mûr.
[^] # Re: Mon avis pro-Ruby on Rails
Posté par ccomb (site web personnel) . En réponse au journal J2EE vs RoR vs Python. Évalué à 2.
Une vue ne doit pas nécessairement être une page web, c'est censé être une vision particulière d'un contenu (par ex un objet). Donc ça peut générer une sortie PDF, une vue par FTP ou par WEBDAV ou en HTML, et dans ce cas une vue doit _utiliser_ un template, mais pas être un template. Il faut limiter au maximum le code contenu dans les templates, car c'est le boulot de la vue.
Dans zope3 une vue peut aussi être juste un morceau de page (un viewlet), qui est intégré dans un gestionnaire de viewlet et qui peut (ou non) utiliser un template pour son rendu. Ca permet de faire des pages avec des boites et des contenus complètement variables et dépendants du contexte, de manière très souple et très intéressante.
C'est vraiment regrettable que la doc et la visibilté de zope3 soient si faibles car les principes utilisés sont vraiments intéressants (on en retrouve dans j2ee, mais pas forcément de la même façon, et sans la soupless de python) et c'est un framework qui est maintenant très stable et très mûr.