mrtopf.de

Recently I tried to use Storm and ToscaWidgets with repoze.bfg to create a simple usermanagement application. Here is a little rundown of what I did.

First I installed repoze.bfg inside a virtualenv:

   mkdir users
   cd users
   virtualenv --no-site-packages .
   source bin/activate

   easy_install repoze.bfg

Some problems might occur on a Mac with Python 2.5 resulting in the need to install PasteDeploy and zope.proxy separately:

    easy_install PasteDeploy
    easy_install zope.proxy

Then you can create a project:

   paster create -t bfg usermanagement

Inside usermanagement you find files like models.py, views.py and so on which is pretty good explained in the bfg documentation.

We now also need to develop this egg:

    cd usermanagement
    python setup.py develop

The basic idea now is to have a UserFolder model which contains BaseUser objects. This led to changing models.py to look like this:

    from zope.interface import Interface
    from zope.interface import implements

    class IUserFolder(Interface):
        pass

    class UserFolder(object):
        implements(IUserFolder)

    class IBaseUser(Interface):
        pass

    class BaseUser(object):
        implements(IBaseUser)

    root = UserFolder()

    def get_root(environ):
        return root

I also changed configure.zcml to reflect that and both use the same default view:

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

      <!-- this must be included for the view declarations to work -->
      <include package="repoze.bfg" />

      <bfg:view
         for=".models.IBaseUser"
         view=".views.my_view"
         />

      <bfg:view
         for=".models.IUserFolder"
         view=".views.my_view"
         />

    </configure>

Adding an addform

Now for adding an addform I wanted to use ToscaWidgets. I installed it manually for now (later this will go into setup.py):

    easy_install ToscaWidgets
    easy_install tw.forms
    easy_install genshi

The latter is needed because otherwise the internally used template engine is not found.

Then I added another function and some imports to views.py:

    from tw.forms import *
    from tw.forms.validators import *
    from tw.api import WidgetsList

    class UserAddForm(TableForm):
        # This WidgetsList is just a container
        class fields(WidgetsList):
            id = HiddenField(default="I'm hidden!")
            username = TextField()
            fullname = TextField()
            email = TextField(
                validator = Email()
                )
            password = PasswordField(
                validator = String(not_empty=True),
                max_size = 10
                )
            password_confirm = PasswordField(
                validator = String(not_empty=True),
                max_size=10
                )

    def addform_view(context, request):
        """show the addform for adding a new user"""
        form = UserAddForm('form')
        form_output = form.display(context)

        return render_template_to_response('templates/addform.pt',
                form=form_output)

and wired this as “addform” into configure.zcml by adding:

    <bfg:view
        for=".models.IUserFolder"
        view=".views.addform_view"
        name="addform"
        />

I started the server by typing

    paster serve usermanagement.ini

inside the project directory and accessed at http://127.0.0.1:5432/addform

We get the following error:

    TypeError: No object (name: ToscaWidgets per-request storage) has been registered for this thread

Looking the example it becomes clear that some WSGI middleware is missing.

Guessing from examples for ToscaWidgets and reading some code I figured out I had to add something to run.py so that it looks like this:

    def make_app(global_config, **kw):
        # paster app config callback
        from repoze.bfg import make_app
        import tw.api

        import usermanagement
        from usermanagement.models import get_root
        app = make_app(get_root, usermanagement)

        app = tw.api.make_middleware(app, {
                    'toscawidgets.framework' : 'wsgi',
                    'toscawidgets.middleware.inject_resources' : True,
                })
        return app

    if __name__ == '__main__':
        from paste import httpserver
        app = make_app(None)
        httpserver.serve(app, host='0.0.0.0', port='5432')

I assume that you can also add stuff like this to usermanagement.ini and this probably is the preferred way of doing it but back then I wasn’t that much used to all the WSGI stuff.

What the middleware here does is also not completely clear to me (and I haven’t yet looked at the code). One part is apparently to make the above error go away which means that it probably injects something into the request. The other part is to inject CSS and JS links into the header. This is similar to the Plone ResourceRegistries the resource stuff in Zope3 ZCML in that each package (widgets mostly in this case) can register their JS and CSS snippets to be included in the document when being rendered.

I also wonder if it’s possible to get around adding this to the middleware stack.

When we now try the app again we notice that addform.pt is missing so we add it to templates:

    <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:tal="http://xml.zope.org/namespaces/tal">
    <head></head>
    <body>
      <h1>Add new user</h1>

      ${form}
    </body>
    </html>

And voila, we have our first form rendered:

Submitting the form

A form is nice but it’s nicer if you actually also store and validate the data. ToscaWidgets keeps the action attribute of the form empty (although I guess you can put something in there somehow) so it will submit to the same URL again.

The example shows how to handle it by checking for the POST method and I do the same just with WebOb which bfg uses. I changed my view to this:

    from formencode import Invalid
    def addform_view(context, request):
        """show the addform for adding a new user"""
        form = UserAddForm('form')
        if request.method=="POST":
            try:
                values = form.validate(request.POST)
                return render_template_to_response('templates/addform_success.pt',
                    values = values)
            except Invalid, error:
                pass
        form_output = form.display(context)
        return render_template_to_response('templates/addform.pt',
                form=form_output)

What’s happening here is basically a check if the request was a POST, then passing the values of the POST to the validate() method of the form and checking for an exception. If there was an exception we simply render the form again like before. If no exception was raised we display the addform_success.pt template:

    <html xmlns="http://www.w3.org/1999/xhtml"

         xmlns:tal="http://xml.zope.org/namespaces/tal">

    <head></head>
    <body>
      <h1>Added new user ${values.username}</h1>

    </body>
    </html>

Note how this is a little different from how Page Template syntax usually looks like. It’s different in so far in that z3c.pt also allows Expression interpolation inside HTML and not only attributes. See the z3c.pt docs (http://pypi.python.org/pypi/z3c.pt) for more information on what’s different.

Now if you pass some wrong data in you should see something like this:

If everything succeeded you can see confirmation we defined above.

So far this works but we are not finished yet. We of course need to store the data somewhere. In production we maybe also want to do some redirect or other means of preventing the form to be submitted twice by accident and e.g.
hitting the reload button on the browser. But that’s for later.

Storage

This is where Storm comes into play, a object relational database mapper which
is developed and used by Canonical. We install it by doing

    easy_install storm

Now we need a database which basically uses our user schema, namely username,
email, password and fullname. For this we create an sqlite database (which btw
you should have installed):

    sqlite3 users.db
    sqlite> CREATE TABLE users (id INTEGER PRIMARY KEY, username VARCHAR, password VARCHAR, fullname VARCHAR, email VARCHAR);
    .quit

Now that we have that table we can add some stuff to models.py to wire it to
the table. I replaced the BaseUser class in models.py with this one:

    class BaseUser(object):
        implements(IBaseUser)

        __storm_table__ = "users"
        id = Int(primary=True)
        username = Unicode()
        password = Unicode()
        fullname = Unicode()
        email = Unicode()

and imported some storm stuff on top:

    from storm.locals import *

We also need to create a database. I did this on module level directly after the import:

    database = create_database("sqlite:users.db")

Now the class should know about our database schema (btw, while I like the
fact that it does not use a metaclass I still would like to have the actual
database schema uncoupled from the actual class to have more flexibility.
Something a la ZPatterns (only old people like me know what this is) might be nice.

Now we need to add some code to views.py. The new view now looks like this:

    from storm.locals import *
    import models

    def addform_view(context, request):
        """show the addform for adding a new user"""
        form = UserAddForm('form')
        if request.method=="POST":
            try:
                values = form.validate(request.POST)

                # open the store
                store = Store(models.database)
                # create a new user and store the data inside
                user = models.BaseUser()
                user.username = unicode(values.get("username",""))
                user.email = unicode(values.get("email",""))
                user.password = unicode(values.get("password",""))
                user.fullname = unicode(values.get("fullname",""))
                # add it to the store
                store.add(user)
                # commit the transaction and flush the store
                store.commit()
                store.flush()
                # now close it again so we are thread safe
                store.close()
                # this is like before
                return render_template_to_response('templates/addform_success.pt',
                    values = values)
            except Invalid, error:
                print error
                pass
        form_output = form.display(context)
        return render_template_to_response('templates/addform.pt',
                form=form_output)

I had some trouble with sqlite and threading as it didn’t work when I defined
the store in models.py and just used it in the view. Thus I now open and close
the store in each transaction. This limitation might not apply to other
database backends though. The question nevertheless is for what database
backend you code so maybe this is safer but maybe also a litte less performant
(but I don’t know what the store compared to the database object actually
does).

If you now start the server again and add some users you should finally see them again inside the database:

    sqlite3 users.db
    sqlite> select * from users
    1|hansi|hdbjdb|Dummy|dummy@dummydummy123.com
    2|hansi2|hdbjdb|Dummy|dummy@dummydummy123.com
    3|foobar|foobar111|Dummy|dummy@dummydummy123.com

Listing users

The userfolder view looks rather boring right now, so why not making this a list of all users?

Let’s define the template first as templates/userfolder.pt:

    <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:tal="http://xml.zope.org/namespaces/tal">
    <head></head>
    <body>
      <h1>User Listing</h1>
      <ul>
          <tal:block repeat="user users">
            <li>
                <a href="/${user.id}">${user.username}</a>
            </li>
          </tal:block>
      </ul>

    </body>
    </html>

We also wire it inside configure.zcml by changing the default
view for the folder:

    <bfg:view
       for=".models.IUserFolder"
       view=".views.userlisting"
       />

(make sure you replace this and not just add it to the file)

And we implement userlisting in views.py as follows:

    def userlisting(context, request):
        """show a userlisting"""
        store = Store(models.database)
        users = list(store.find(models.BaseUser).order_by(models.BaseUser.username))
        return render_template_to_response('templates/userfolder.pt',
                users=users)

If you restart you will see the userlisting at
http://localhost:5432/ (as the userfolder is our root object at
the moment). The only problem is if you click on a user because there is no
traversal yet defined for this and bfg produces a 404.

Let’s change this by adding a __getitem__() to the BaseUser class:

    def __getitem__(self, id):
        store = Store(database)
        user = store.get(BaseUser, int(id))
        return user

After a restart we can already click on the users but the template does not
say that much about them. So we need a new one and also need to create a
separate view for them. I added the following to views.py:

    def userdetails(context, request):
        return render_template_to_response('templates/userdetails.pt',
                                           context = context)

And we need to create some template for it as templates/userdetails.pt:

    <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:tal="http://xml.zope.org/namespaces/tal">
    <head></head>
    <body>
      <h1>User Details for ${context.username}</h1>

      <table border="0" cellspacing="5" cellpadding="5">
        <tr>
            <td>Username:</td>
            <td tal:content="context.username"></td>
        </tr>
        <tr>
            <td>Fullname:</td>
            <td tal:content="context.fullname"></td>
        </tr>
        <tr>
            <td>E-Mail:</td>

            <td tal:content="context.email"></td>
        </tr>
      </table>
    </body>
    </html>

Now we just need to wire this view to the model, which means changing it in configure.zcml:

    <bfg:view
       for=".models.IBaseUser"
       view=".views.userdetails"
       />

And that’s all there is to it. Much is of course still missing, such as deleting. Next steps could be to abstract things a bit more to have some sort of schema which handles storage and form generation all in one.

Ähnliche Artikel

• Das Python-Barcamp zur 1. PyCon Deutschland
• Scaling with NoSQL – Recording from NoSQL Live Boston
• Malthe about “Otto” (Plone Conference 2009 Open Space Session)