Personal tools

Andrew Mleczko

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:

PASTER TEMPLATE

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”):

...
config.include(myapp.fainit)
...

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. 

FANSTATIC

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:

CUSTOMISABLE ACTIONS

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)

 

I18N

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

[app:pyramid]
...
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:

config.formalchemy_model_view('admin',
                              model='pyramidapp.models.Foo',
                              context='pyramid_formalchemy.resources.ModelListing',
                              renderer='templates/foolisting.pt',
                              attr='listing',
                              request_method='GET',
                              permission='view')

and per Model:

config.formalchemy_model_view('admin',
                              model='pyramidapp.models.Foo',
                              context='pyramid_formalchemy.resources.Model',
                              name='',
                              renderer='templates/fooshow.pt',
                              attr='show',
                              request_method='GET',
                              permission='view')

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

Widgets

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
User.group.set(renderer=pyramid_autocomplete(filter_by='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 pyramid_formalchemy.events.subscriber 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

 

Summary

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.

CrudSprint2011

You can find more sprint photos here - http://www.flickr.com/photos/tags/crudsprint2011

May 06, 2011

Varnish purge after article rate

Filed Under:

For one of the projects we are using a very aggressive Varnish configuration. We are caching also html (not for long but still) for anonymous users. It could be a problem if you have some dynamical features - like rating. 

But not any more. Using this simple vcl add-on you can purge article view after making a vote:

sub vcl_recv {
...
   if (req.http.Cookie && req.http.Cookie ~ "statusmessages=") { 
       purge("req.url ~ " req.url);
       pass;
   }
...
}

 

It simply checks if you have a statusmessages cookie in request (after rating an article Plone is displaying confirmation status message) and purge current url from cache. Simple, clean and it works!

Apr 26, 2011

Pyramid CRUD sprint

Filed Under:
Pyramid

After few months of discussions it is finally here: Pyramid CRUD sprint. It will be held in Ferrara just before EuroPython (June 16-19). Everyone is welcome! We will focus on two main goals: 

  • make the CRUD more flexible then it is right now (using ZCA for view and subscribers registrations), increase test coverage and make it production ready
  • add missing widgets and fix existing one
 

So if you want to taste classical Italian kitchen, visit UNESCO World Heritage Site and improve Pyramid - join us!

For more details check www.coactivate.org/projects/pyramid-crud-sprint

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,
                      factory='pyramid_formalchemy.resources.Models',
                      view='pyramid_formalchemy.views.ModelView',
                      package=None, models=None, forms=None, session_factory=None):
...
config.add_view(context='pyramid_formalchemy.resources.ModelListing',
                    renderer='pyramid_formalchemy:templates/admin/listing.pt',
                    attr='listing',
                    request_method='GET',
                    permission='view',
                    **kw)


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:

  <view
      for=".interfaces.IModel"
      view=".listing"
      renderer="templates/my_model_listing.pt"
      permission="list"
  />


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 :-)

Apr 12, 2011

Plone and Pyramid talk proposed for EuroPython

I have proposed a talk "How to build complex web applications having fun?" for this year's EuroPython.

This year, EuroPython is in Florence, Italy, which is ca. 140km from where I live now. It couldn't get easier to attend and propose a talk:

Web development is a complexity challenge nowadays. Growing number of functionalities results in customer expectations increase which makes project design more difficult. Using proper tools that suite your customer needs is essential.

In this talk I would like to present two successful stories using closely together Pyramid and Plone. Basing on these examples I wished to highlight the main reasons for using Plone as a CMS only and letting Pyramid do the rest (vertical application). Moreover, I will underscore good and bad practices during integration process and how to make farsighted architectural decisions in a right moment.

This year, everyone who has bought EuroPython ticket can vote. So If you have one and you'd like to see this talk, vote for it directly from abstract page.