Connection between WSGI, Repoze, Deliverance WSGI WSGI Zope Repoze Deliverance
WSGI – The Problem ● Lots of web frameworks: Zope, Quixote, Webware, SkunkWeb and Twisted Web etc. ● Applications written for one framework often weren't compatible with the server components of the others ● Made the choosing a Python web framework hard as there were so many different and incompatible options ● The PEP compares the situation to Java which had its Servelet API
● It is a callable (in this case a simple function)
taking environ and start_response as
positional parameters.
● It calls start_response() with a status code
and a list of tuple pairs of headers before it
returns a value. It should only be called
once.
● The response it returns is an iterable (in this
case a list with just one string).
WSGI - Middleware 1. Acts like a WSGI application 2. Follows the WSGI Spec 3. Looks like a server to another piece of middleware or an application 4. Could decide to give its own response, or call your app
WSGI Summary ● WSGI isn't too complicated ● If your app is WSGI compliant you can instantly deploy it on a number of servers ● There are lots of powerful tools and middleware already in existence and you can easily re-use them -> see wsgi.org ● I'll be talking about Pylons later today which is one of the first projects to use WSGI throughout its stack.
Repoze – The Problem
Zope isn't compatible with WSGI
Top-Level Packages
repoze.zope2
repoze.plone
repoze.grok
repoze.zope2
Re-implementation of Zope 2's ZPublisher to fit into a WSGI stack "natively".
As a result, run Zope2 within Apache using mod_wsgi.
Goal: 100% backwards compatibility with all Zope 2 products.
Goal: 100% egg-based package installation.
Goal: move many Zope 2 features out into middleware.
Repoze - Installing and Starting
easy_install and virtualenv based via http://repoze.org/quickstart.html.
Buildout-based via http://svn.repoze.org/buildouts.
bin/paster serve etc/zope2.ini
Motivation to Deliverance
Zope and Content Management System forces web designers to learn a complex page templating language. It makes designing web pages slow to develop and hard to debug. There should be an easier way to take the content from a CMS and style it in various ways without understanding the architecture of the CMS and without even knowing the origin of the content. This would create a formal distinction between content production and content delivery.
Deliverance Components
The content is the information you want to style with the theme. It can be a live website or a static file, specified with a URI.
The theme contains the style and layout information you want to apply to the content. It can be a live website or a static file, specified with a URI.
The rules tell Deliverance how to apply the theme to the content.
Deliverance. Simple Example. Page with content <html> <head> <title>my boring todo page</title> <head> <body> <div id="todo"> <h1>Things To Do</h1> <ul> <li>Feed the cat</li> <li>Wash the dishes</li> </ul> </div> </body> </html>
Deliverance. Simple Example. Page with theme <html> <head> <style type="text/css"> div {background: #00ffdd;} li {list-style-type: disc;} </style> <title>my exciting home page</title> </head> <body> <h1>Deliverance User's Exciting Page</h1> <div id="wishes"> I wish my todo list looked this cool </div> </body> </html>
0 comments
Post a comment