Bfg Ploneconf Oct2008

therepoze.bfg

web frameworkPresented By

Chris McDonoughAgendaless ConsultingPlone Conference 2008

• About a year old.

• Allow Zope developers to use WSGI technologies more easily.

• Allow non-Zope developers to use Zope technologies without using all of Zope.

• repoze.bfg: July 2008

• Chris McDonough, Tres Seaver, Paul Everitt, Carlos de la Guardia, Malthe Borch, Stefan Eletzhofer, Fernando Neto-Correa.

• Big f'ing gun -OR- big friendly giant: you choose.

WHY?• Zope2: still kicking, but only due to Plone

• Zope3: big, many dependencies. App developers encouraged to use CA.

• Grok: "making Z3 easier to use" (see Zope 3).

• Django: nice, but Z2-like.

• Pylons/TG2: nice, but geared towards RDB / URL dispatch apps.

• Others: not Zope-like / no traction.

Goals

• Familiarity: like Zope, but less

• Simplicity: pay only for what you eat

• Speed: go as fast as possible while still actually doing something

• Documentation: the lack of formal documentation of a feature or API is a bug

• Collaboration: culture of using and promoting non-Zope stuff

What BFG Does

• Maps URLs to code

• Provides mechanisms that allow developers to make declarative security assertions

• Provides text and HTML templating facilities

• Allows for use of existing Zope libs (via ZCML).

What BFG Doesn't Do

• Database / persistence

• Sessions

• Indexing / searching

• ZMI / TTW code

• View code sharing with Z3 / Five

• etc...

The Application is the Application

• You don't write "Products" to plug into BFG. Extensibility is via normal Python packages and ZCML as necessary.

• An application is generated for you; you develop the application and run the application; you don't run the framework.

Graph Traversal and URL Dispatch

• BFG supports both graph traversal (ala Zope) and "URL dispatch" (ala everything else) to map URLs to code.

• URL dispatch is backed by Routes.

Zope CA

• The Zope Component Architecture was used to construct BFG.

• BFG application developers don't need to use the CA. It's a framework implementation detail.

Components

• WSGI pipeline.

• Router (aka Publisher).

• "Application registry" (ZCML / decorators).

• Views (aka "controllers" in Pylons/Rails).

• Templates (chameleon/XSL/other).

DependenciesPaste-1.7.1-py2.4.egg zope.deferredimport-3.4.0-py2.4.eggPasteDeploy-1.3.2-py2.4.egg zope.deprecation-3.4.0-py2.4.eggPasteScript-1.6.3-py2.4.egg zope.event-3.4.0-py2.4.eggRoutes-1.9.2-py2.4.egg zope.exceptions-3.5.2-py2.4.eggWebOb-0.9.2-py2.4.egg zope.hookable-3.4.0-py2.4-macosx-10.5-i386.eggzope.i18n-3.5.0-py2.4.egg zope.proxy-3.4.1-py2.4-macosx-10.5-i386.eggelementtree-1.2.6_20050316-py2.4.egg zope.i18nmessageid-3.4.3-py2.4-macosx-10.5-i386.egglxml-2.1.1-py2.4-macosx-10.5-i386.egg zope.interface-3.4.1-py2.4-macosx-10.5-i386.eggpytz-2008c-py2.4.egg zope.location-3.4.0-py2.4.eggsetuptools-0.6c8-py2.4.egg zope.publisher-3.5.3-py2.4.eggzope.schema-3.4.0-py2.4.egg zope.traversing-3.5.0a3-py2.4.eggz3c.pt-1.0a1-py2.4.egg zope.security-3.5.1-py2.4-macosx-10.5-i386.eggzope.component-3.4.0-py2.4.egg zope.testing-3.5.1-py2.4.eggzope.configuration-3.4.0-py2.4.egg

Many are due to inappropriate dependencies in Zope eggs.

How it Works

Models• "content" objects

• typically arranged in a graph (although not required)

• For Zope people: think ZODB

• ZODB not required for repoze.bfg applications: filesystem directories, XML documents, RDF graphs, SQL databases, etc. can be the source of model data

A Modelfrom zope.interface import implementsfrom zope.interface import Interface

class IMyModel(Interface): pass

class MyModel(object): implements(IMyModel) def __init__(self, name): self.name = name

Views

• Views are functions which accept a "context" (a model object) and a "request".

• Views must return a response. Unlike Zope.

• The view may use a template to generate the response body, or not.

A View

from webob import Response

def hello_world(context, request): return Response('Hello world!')

A View That Renders a chameleon.zpt Template

from repoze.bfg.chameleon_zpt \ import render_template_to_response

def hello_world(context, request): render_template_to_response( 'templates/hello.pt', context=context, myname='chris')

Using Model Data from a View

from webob import Response

def hello_world(context, request): name = context.name return Response('Hello %s!' % name)

Templates• Default templating engine: chalmeleon by

Malthe Borch. ZPT or Genshi syntax. ~ 10X - 15X faster than zope.pagetemplate.

• Included: XSLT.

• Add-on: jinja2 (Django-style, via repoze.bfg.jinja2)

• Any other you'd like to use; bindings are simple to create (see the jinja2 bindings).

Traversal• The BFG router traverses the model graph based on

the path segments in the URL (like Zope does).

• If traversal "falls off" the end of the model graph, and there are path segments remaining, it looks for a view registered against the interface of the last model traversed using the next path segment as the view name.

• If there are no segments remaining, the default view is used.

• If no view is found, a 404 not found error is returned.

View Registrations<configure xmlns="http://namespaces.zope.org/zope" xmlns:bfg="http://namespaces.repoze.org/bfg" i18n_domain="repoze.bfg">

<include package="repoze.bfg" />

<— default view for .interfaces.IMyModel —> <bfg:view for=".interfaces.IMyModel" view=".views.my_view" />

<— named view for .interfaces.IMyModel —> <bfg:view for=".interfaces.IMyModel" view=".views.other_view" name="other" /></configure>

View Registrations via Decorators

from webob import Responsefrom repoze.bfg.convention import \ bfg_view

@bfg_view(name='hello.html')def hello_world(context, request): name = context.name return Response('Hello %s!' % name)

Speed<html xmlns="http://www.w3.org/1999/xhtml" xmlns:tal="http://xml.zope.org/namespaces/tal"> <head> <title tal:content="context.title">The title</title> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> </head> <body> <h2><span tal:replace="context.title_or_id()">content title or id</span> <span tal:condition="context.title" tal:replace="context.title">optional template title</span></h2>

This is Page Template <em tal:content="request.view_name">template id</em>. </body></html>

Zope 2.10 view page template: 309 req/secvs.

BFG view + chameleon.zpt template: 869 req/sec

Memory Usage and Process Sharing

• Existing Zope 2 and Zope 3 apps cannot run side-by-side in the same process due to globals sharing (ZCML global registry, database references); BFG has been written to make such a configuration work by default.

• Lower memory requirements per application instance (BFG minimum ~15 MB vs. Zope 3 minimum ~50MB).

Startup Speed

• repoze.bfg caches the ZCML registry as a pickle for faster startup.

• Startup time with a single view defined: 900ms.

Paste-Derived Reload Feature

[chrism@vitaminf myproj]$ ../bin/paster serve myproj.ini —reloadStarting subprocess with file monitorStarting server in PID 61405.serving on 0.0.0.0:6543 view at http://127.0.0.1:6543

/Users/chrism/projects/repoze/bfgenv/myproj/myproj/run.py changed; reloading...—————————— Restarting ——————————Starting server in PID 61409.serving on 0.0.0.0:6543 view at http://127.0.0.1:6543

Template Auto-Reload Feature

• Templates auto-reload by default.

• This can be turned off for speed.

WSGI-Middleware-Derived Features

• Profiler (repoze.profile)

• Alternate exception handlers (paste.evalexception).

• Caching (repoze.accelerator)

• Theming (Deliverance).

• Transaction management (repoze.tm2)

• etc...

Project Setup Demo

Futures

• Vudo CMS (http://docs.vudo.me) to be implemented using repoze.bfg, hopefully. Work towards this: repoze.bfg.skins, repoze.bfg.layout, repoze.bitblt, repoze.squeeze.

• BFG will stay minimal. Add-ons and superframeworks like vudo and repoze.lemonade will provide functionality.

The End

• For a more in-depth exploration of how a bfg app is written, see the screencast at

http://static.repoze.org/presentations/repozebfg-wiki.mov