Personal tools


Jun 20, 2011

Pyramid CRUD sprint summary

Filed Under:

Pyramid CRUD sprint is over. It was an amazing event thanks to Gaël Pasgrimaud and Patrick Gerken. We have been sprinting in Redturtle's office to improve pyramid_formalchemy and fa.jquery. We have archived most of the sprint goals!

Patrick was working on the first two tasks:


It can be used to add a skeleton to an existing project or to create a new project. If you create a new project, you must first install pyramid_formalchemy in your python environment, either with pip:

$ pip install pyramid_formalchemy

or with easy_install:

$ easy_install pyramid_formalchemy

Only after that, the paster template becomes available. The template was made with the idea that it can be used to extend existing applications. It does not create an app for you. The provided template works well with pyramid_alchemy, pyramid_routesalchemy and akhet. To bootstrap an application, call paster like that:

$ paster create -t akhet -t pyramid_fa myapp

The application is created by akhet, akhet does not know about pyramid_formalchemy, and pyramid_formalchemy cannot modify the app configuration. So you have to do this by hand. First, you must add the install dependency like explained earlier. Second, you must add the following line in the main method that returns the wsgi app, directly after Configurator has been created (The example assumes that the Configurator instance is stored under the name “config”):


To add the minimum configuration to an existing application, you should be able to run:

$ paster create -t pyramid_fa myapp

All files that paster creates are prefixed with fa, and should not interfere with existing code. 


Patrick's second task was fanstatic integration. Fanstatic is a small but powerful framework for the automatic publication of resources on a web page. Think Javascript and CSS. It just serves static content, but it does it really well. Integrating it with fa.jquery was a time consuming task but we managed to get a working proof of concept. I will blog more details when we publish something stable.

Next tasks were handled by Gaël:


Action are basically links or input button. By default there is only one category buttons which are the forms buttons but you can add some categories like this:

>>> from pyramid_formalchemy.views import ModelView
>>> from pyramid_formalchemy import actions
>>> class MyView(ModelView):
...     actions_categories = ('buttons', 'custom_actions')
...     defaults_actions = actions.defaults_actions.copy()
...     defaults_actions.update(edit_custom_actions=Actions())


Where myactions is an Actions instance

You can also customize the actions per Model:

>>> from sqlalchemy import Column, Integer
>>> from sqlalchemy.ext.declarative import declarative_base
>>> Base = declarative_base()
>>> class MyArticle(Base):
...     __tablename__ = 'myarticles'
...     edit_buttons = Actions()
...     id = Column(Integer, primary_key=True)


The available actions are: listingnewedit

But you can add your own:

>>> from pyramid_formalchemy.views import ModelView
>>> from pyramid_formalchemy import actions
>>> class MyView(ModelView):
...     actions.action()
...     def extra(self):
...         # do your stuff
...         return self.render(**kw)



Yes, pyramid_formalchemy is now i18n! You need to add to your pipeline:

default_locale_name = en
available_languages = fr en

and that's it! Right now we have english and french translations but others are coming.

I was working on the first three tasks: 

View customization

This was one of the main sprint tasks - to have a possibility to customize CRUD views per model.  You can register them simply like that:


and per Model:


formalchemy_model_view is an extension for config.add_view so you can use all view specific kwargs.


We were able to finish simple implementation of autocomplete widget. It's not yet fully documented but it will be released in pyramid_formalchemy 0.4.  Here is how you use it:

from pyramid_formalchemy.renderers import pyramid_autocomplete'name'))

where User is your fieldset and group is your relation field; filter_by parameter is the SQLAlchemy column you want to filter (autocomplete) on. 

Events hooks

We have provided four events: 

  • IBeforeValidateEvent
  • IAfterSyncEvent
  • IBeforeDeleteEvent
  • IBeforeRenderEvent

There are also two more specific render evnts: 

  • IBeforeShowRenderEvent
  • IBeforeEditRenderEvent

You can use decorator to use them:

from pyramid_formalchemy import events
from pyramidapp.models import Foo

@events.subscriber([Foo, events.IBeforeValidateEvent])
def before_foo_validate(context, event):
   #do your stuff here



It was a very productive four days. Thanks again for all your help. We should release new versions of pyramid_formalchemy and fa.jquery in the following days. If you don't want to wait - grab the development versions on github.


You can find more sprint photos here -

Apr 15, 2011

Pyramid CRUD vol.2

Filed Under:

In my previous post I was trying to see what could be the benefit for Pylons Community to have a crud. We have a working prototype based on bfg. Now we would like to rewrite it for Pyramid. I've received interesting feedback, but the most promising was pyramid_formalchemy posted by Gael.

What I miss in pyramid_formalchemy

I will start with description of our use case. At the moment we are using our CRUD to handle most of the form generation and CRUD operations. We are using it in several projects, one of them with ca. 100 models. The part of the application that is exposed to anonymous user (like registration) or it's more complex (like wizard multip-step forms) we are handling with formish. For those 100 models we are using heavily ZCA for customizing View/List templates. As far I can see in the pyramid_formalchemy source code:

def formalchemy_admin(config, route_name,
                      package=None, models=None, forms=None, session_factory=None):

you can only pass one ModelView for config registration and practically you can't customize any of the templates per model.
What we would actually like to have is a ZCA registration, like:


ZCML is of course optional...

Other benefit of this approach is a possibility to register other non-crud views (not only list/add/view/edit/delete) only for specific model (can be helpful for some of the widgets implementation, i.e. autocomplete).

This is our main concern.

At the end we miss some widgets (which should be part of fa.jquery project and can be extended easily). One of the most interesting one is relation widget (with several variations),  which right now is missing :-)

Feb 10, 2011

Pyramid CRUD

I have been using Pyramid/BFG in several our projects. It really rocks. Probably you already know that. What I think could be an extremely useful add-on is a CRUD. For our internal usage (more as a proof-of-concept) we have developed one - traversal with SQLAlchemy support. Now we want to make it more generic and open-source. Interested in?

What we have is a working version of a traversal CRUD. General concept is similar to Sergey Volobuev Kelpie. Everything is based on repoze.bfg 1.2 (though it should work smoothly on 1.3).

Model definition is done using SQLAlchemy declarative approach.  This choice provoke us to use  FormAlchemy as a form generator (with fa.jquery widget support). It's easy to start with but difficult to extend later.  That's why it's the first thing we would like to change in the future.  Everything is glued together with bfg hybrid traversal approach

What we are planing to do (probably not exactly in that order):

  • check if somebody else didn't start similar project and maybe share concepts or do it together
  • check possibility of integrate existing solutions with Pyramid
  • reuse what can be reused from our bfg crud and move it to Pyramid
  • organize a python sprint that will work on these topics
CRUD section view:
 CRUD - section view
CRUD item view:
CRUD - item view
CRUD item edit:
CRUD - item edit