Using lesscss with Pyramid and Fanstatic

We all know twitter bootstrap. It became really popular in the past few months. We saw it all over the internet with same header and same colors.

In this post I'll show you how to customize twitter bootstrap with pyramid and Fanstatic. In other words, how to use lesscss (the language used by bootstrap) with pyramid.

lesscss allow to write dynamic css stylesheets with a specific language. You can find a lot of examples and documentation on their website.

In this example we will use:

  • pyramid_fanstatic: A Fanstatic integration as a pyramid tween. It also provide a pyramid scaffold and an helper to reload the development server when a static resource change.
  • js.lesscss: A Fanstatic package to embed lesscss as a python dependencie. This package was created by Stéphane Klein and I've update it to use lessc to compile .less files

Ok. Let's go!

Create a virtualenv and install a bunch of packages:

$ virtualenv myenv
$ cd myenv
$ source bin/activate
$ pip install pyramid_fanstatic js.lescss

Now that we have a virtualenv with all dependencies we need to create a pyramid application:

$ pcreate -s starter -s pyramid_fanstatic lesscss_example
$ cd lesscss_example

A README_FANSTATIC.txt file will show you how to finalize your installation. We need that because the pyramid_fanstatic scaffold does not redifine files like setup.py and __init__.py so you can use it with all scaffolds included in pyramid and other projects. Here is the file content:

To finalize your installation you'll need to follow those steps.

Add those line the app:main section of your development.ini:

[app:main]

fanstatic.bottom = true
fanstatic.debug = true

Add some requirements to your setup.py:

requires = ['pyramid', 'pyramid_debugtoolbar',
            'pyramid_fanstatic',
            # if you want to use lesscss
            #'js.lesscss'
            ]

Also add those entry points to the same file bellow the paste.app_factory:

# Fanstatic resource library
[fanstatic.libraries]
lesscss_example = lesscss_example.resources:library

# A console script to serve the application and monitor static resources
[console_scripts]
pserve-fanstatic = lesscss_example.resources:pserve

You also need to add pyramid_fanstatic tween to your application. Add the following to your __init__.py file:

config.include('pyramid_fanstatic')

Run python setup.py develop to get the pserve-fanstatic script available.

That's it. Once all those steps are done we can have a look at the resources.py created by pyramid_fanstatic scaffold. Here is a modified version to activate the main.less resource:

from fanstatic import Library
from js.lesscss import LessResource

library = Library('lesscss_example', 'resources')

less_resource = LessResource(library, 'main.less')


def pserve():
    """A script aware of static resource"""
    import pyramid.scripts.pserve
    import pyramid_fanstatic
    import os

    dirname = os.path.dirname(__file__)
    dirname = os.path.join(dirname, 'resources')
    pyramid.scripts.pserve.add_file_callback(
                pyramid_fanstatic.file_callback(dirname))
    pyramid.scripts.pserve.main()

The trick is to use a LessResource instead of the standard Fanstatic Resource. This class compile the .less file at init time. The pserve() function is the target of our pserve-fanstatic entry point. It run pyramid's pserve script after adding the Fanstatic resources to the list of files watched by the monitor used to reload the application when a file changed. Don't forget the --reload option when running this script else the monitor is not initialized.

Modify the main.less file in the resources directory:

$ cat lesscss_example/resources/main.less                                                                    ✹
// main lesscss style sheet for lesscss_example

@color: #ccc;
@border: thin solid black;

blockquote {background-color: @color; border: @border;}

Ok, we are ready to build our first view. Just add this to your __init__.py:

from lesscss_example.resources import less_resource


def home(request):
    """a simple view to test our resource"""
    less_resource.need()
    return {}

Fanstatic use a thread local registry to store the resource used by a request so the only thing needed is to use the resource method .need() and this resource will be injected in your html.

Let's register the view and it's associated route:

config.add_route('home', '/')
config.add_view(home, route_name='home', renderer='templates/mytemplate.pt')

mytemplate.pt is a very basic template with an empty <head />. Fanstatic will inject resources tags for you. You remember that ?

Easy, right ? Check the result with pserve development.ini. At this time nothing should work. Why ? Because we want to use lessc and we dont have it.

I'll not cover node.js / less installation here. You can find a lot of tutorial on other places. You can also find a buildout.cfg to get lessc in your buildout at the bottom of this post. Notice than lesscss only work with node 0.4.12 for me at the moment.

pserve-Fanstatic will try to find lessc binary in the following directories:

  • $PWD/bin
  • $HOME/bin
  • /usr/local/bin
  • /usr/bin

Once you got a lessc binary, run pserve-fanstatic:

$ pserve-fanstatic --reload development.ini

This will run the app in "compile" mode. This mean that the .less is compiled when you are starting the server but the browser will use the .less file. When you are ok with the result, restart the server with the standard pserve script. Your browser will use a compiled version of the .less file (.less.min.css).

You can have a look at the minified resource:

$ cat lesscss_example/resources/main.less.min.css
blockquote{background-color:#cccccc;border:thin solid #000000;}

That's nice. How about twitter bootstrap ? Let's try it. Checkout bootstrap in your resources/ directory:

$ git clone https://github.com/twitter/bootstrap.git lesscss_example/resources/bootstrap

And register bootstrap.less in the Fanstatic registry. Add this to your resources.py file:

bootstrap = LessResource(library, 'bootstrap/lib/bootstrap.less')

Register a view to test the new resource:

from lesscss_example.resources import bootstrap


def home2(request):
    """a simple view who use bootstrap"""
    bootstrap.need()
    return {}


config.add_route('bootstrap', '/bootstrap')
config.add_view(home2, route_name='bootstrap',
                      renderer='templates/mytemplate.pt')

And thats it. Run pserve-fanstatic and go to /bootstrap. Play with the variables.less and have fun. You'll get a bootstrap.less.min.css usable in production.

As a bonus I'll show how to use buildout to make all that stuff easier. This will install node.js and lessc so it can be used by pserve-fanstatic.

[buildout]
# run eggs, pserve and node parts
parts = eggs node
# set our project as a develop egg
develop = .
# dont check for new releases
newest = false
# prefer stable release (only buildout can do that!)
prefer-final = true

[eggs]
# the eggs part will install all dependencies and setup our application in
# development mode
recipe = z3c.recipe.scripts
eggs =
    pyramid
    lesscss_example

[node]
# install node.js + lessc
recipe = gp.recipe.node
# you can use an existing node binary
#binary = /usr/local/bin/lessc
npms = less
scripts = lessc

That's all... All this code is available as a github repository.

Django is awesome

10/14/2011 python django

Yeah, Django is awesome. You have to know that I use Django every days at work. But... there's some points that I really dislike. I guess I'm the best french django opponent. Now I can show this post when people ask me why.

Django is monolithic

Everybody know that. No discussion is needed.

Django has a real community

Some Django's third party products are great. But all contribution made for Django are only for django. Django has it own middleware specification even if the pep 333 exists. That's sucks. What if I want to use all the great stuff with my own wsgi framework ?

Next point: Django use svn. What ? This old VCS ? Why I can't contribute by forking on github or bitbucket ? Is that a real modern community ?

Django templating can't contain some logics

Oh yeah, that's a great philosophy. But I'm a mature developer and I want to use a simple modulo in a template without having to write a 20 lines template tag. I promise that I don't put so much logics in my template.

You can use Jinja!

Yes, I can. But then I need to forget all the great stuff provided by third party products. So, in fact, I can't.

Webob is great but Django's Request/Response is better

Web0b is a 200% well tested library. It just work. Why this is not used by Django ? Is it so hard ? Some people tried to include that library in Django but... it just fail. See this page. No longer maintained... I guess the author switch to another framework.

Packaging

Is that really exist ? No, It doesn't matter. All my python code should go in app/ then you can checkout my code in your apps/ folder. no problem. After a few years passed with Tarek "el packager" Ziade I became sick when I see the code generated by Django's templates.

Django has view class !!

That's the good news of the latest release. Awesome ! That's just made me remember Zope 2. I guess that this post explain this better than I can.

EOP

End Of Post. I guess I've pointed all things I dislike in Django. Or maybe it's just a work in progress...

Django still great. But it can be better without so much effort. Use WebOb... Add a setup.py to project/app templates... Use a Pyramid like renderer to allow more than one template engine... Use github... Please, just do it, Django people!

Using restkit proxy in your WSGI app

06/33/2010 python wsgi proxy

Here is my use case. A few days ago I've wrote an application to mirror my Flickr accounts. The pics are downloaded on file system and the metadata are stored in CouchDB. Now I use the Flickr interface to upload and tags pics but I got my own data on my own server. That's always cool.

Well done but now it can be useful to have a small web app to see the pics. Right ? That's what I've do. Since I love jQuery and CouchDB is full json compliant I don't want to write a complex app with tones of python code. So the idea is to have a small wsgi app to only serve static javascripts/html/css files and a proxy app to serve json by proxying CouchDB.

For now I'm using WSGIProxy. The code is very simple and look like this:

from wsgiproxy.exactproxy import proxy_exact_request
from webob import Request

class Proxy(object):
    def __init__(self, db=None, **kwargs):
        self.db = db
    def __call__(self, environ, start_response):
        req = Request(environ)
        if req.method == 'GET':
            req.server_name = '127.0.0.1'
            req.server_port = 5984
            req.script_name = ''
            req.path_info = '/%s%s' % (self.db, req.path_info)
            resp = req.get_response(proxy_exact_request)
            resp.content_type = 'text/jasacsript'
        else:
            resp = exc.HTTPForbidden()
        return resp(environ, start_response)


def make_app(global_conf, **local_conf):
    conf = global_conf.copy()
    conf.update(local_conf)
    return Proxy(**conf)

That's cool and simple and ok for small files. But if you want to handle large request WSGIProxy will raise a MemoryError. This is no longer fun. I've already sent a patch but don't want to bother the Paste team with that.

Then I've try to use restkit and thought that it can be the best library to wrote a proxy app. restkit manage a pool of http connection and handle large file request in a clean way.

The result is a small contribution. A set of WSGI applications included in the wsgi_proxy extention.

Here is a simple Paste config file to show own to use the proxies:

[server:main]
use = egg:Paste#http
port = 4969

[app:main]
use = egg:Paste#urlmap
/couchdb = couchdb
/ = proxy

[app:couchdb]
use = egg:restkit#host_proxy
uri = http://localhost:5984/mydb

[app:proxy]
use = egg:restkit#host_proxy
uri = http://benoitc.github.com/restkit/
max_connections=50
allowed_methods = get head post

No code needed. Cheers.

You can also use the Proxy class to proxify clients request and transform the response on the fly:

from webob import Request
from restkit.ext.wsgi_proxy import Proxy

proxy = Proxy()

def application(environ, start_response):
    req = Request(environ)
    req.environ['SERVER_NAME'] = 'example.com'
    req.environ['SERVER_PORT'] = '80'
    # do stuff
    ...
    resp = req.get_response(proxy)

    # do stuff ...
    ...

    return resp(environ, start_response)

I've also tried to replace WSGIProxy in deliverance with an ugly monkey patch:

from restkit.ext.wsgi_proxy import Proxy
from wsgiproxy import exactproxy
print 'Patching exactproxy with restkit proxy'
exactproxy.proxy_exact_request = Proxy(max_connections=4, allowed_methods=['GET', 'HEAD', 'POST']).__call__

It work perfect.

Avoid CSRF in the Ajax world

Most (good) web frameworks have a way to avoid Cross Site Request Forgery but in the Ajax world it's not so easy.

Here is my solution. First generate a secret key (sha1 of the current date or whatever) store it in user's session and show an hidden field in the requested webpage:

<input type="hidden" id="_req" name="_req" value="your secret key" />

Here is a snippet for Pylons:

def secure_field(with_id=False):
    value = request.environ.get('_req', None)
    if value is None:
        # generate a key if not already done for the request
        value = sha.new('%s-%s' % (datetime.now(), random.random())).hexdigest()
        session['_req'] = value
        request.environ['_req'] = value
        log.info('setting secure key to %r', value)
    if with_id:
        return hidden('_req', id='_req', value=value)
    return hidden('_req', value=value)

Notice that the field can be render multiple time with the same key (but only one with an id because of XHTML). The key is generated per request. This allow to have multiple _req fields in the same page so you can also add it to non-Ajax forms (and secure them too).

Then you need to POST this key on each Ajax request. Here is a wrapper for jQuery's post method:

post: function(url, data, callback, dataType) {
    // wrap $.post to add _req field
    if (!dataType) dataType = 'html';
    if (typeof(data) == typeof('')) {
        // $(form).serialize() return a string
        data += '&_req='+$('#_req').val();
    } else {
        data['_req'] = $('#_req').val();
    }
    $.post(url, data, callback, dataType);
}

The _req key is added to each POST request.

Last thing. You need to check that the key stored in user's session is also in the POST data. Here two Pylons decorators to avoid illegal requests:

@decorator
def secure_post(func, *args, **kwargs):
    """return html"""
    if request.method == 'POST':
        _req = session.get('_req', None)
        if _req is not None and _req == request.POST.get('_req'):
            del request.POST['_req']
            data = func(*args, **kwargs)
            return data
    if request.environ.get('paste.testing') is True:
        return func(*args, **kwargs)
    return _('Forbidden')

@decorator
def secure_json(func, *args, **kwargs):
    """return json"""
    if request.method == 'POST':
        _req = session.get('_req', None)
        if _req is not None and _req == request.POST.get('_req'):
            del request.POST['_req']
            data = func(*args, **kwargs)
    if request.environ.get('paste.testing') is True:
        data = func(*args, **kwargs)
    else:
        data = dict(error=_('Forbidden'))
    response.content_type = 'application/json'
    return json.dumps(data)

That's it. Now you are sure that all Ajax requests came from the user's web page. Cheers.

Of course the key is valid for more than one Ajax request. You may regenerate it for each main html page. May be this can be improved to change the key for each request including Ajax's but... It's already secure. Right ?

FormAlchemy 1.3 status

FormAlchemy 1.3 is released. From the website:

FormAlchemy eliminates boilerplate by autogenerating HTML input fields from a
given model. FormAlchemy will try to figure out what kind of HTML code should
be returned by introspecting the model's properties and generate ready-to-use
HTML code that will fit the developer's application.

Why I choose FormAlchemy instead of another form library ? Everybody knows that explicit is better than implicit. So most of form libraries use a schema to define how widgets are render. FormAlchemy avoid that by using the schema of the data model (SQLAlchemy mappers at the origin). So it generate forms implicitly using your explicit data model.

Another reason is that FormAlchemy is independent. This mean that you can use it in Pylons, Django, repoze.bfg, bobo and (put your favorite framework here).

Thats cool. But we can do more. And that's what we tried to do. SQLAlchemy is not the only library to define data model. So let use the others !

Using couchdbkit

couchdbkit allow to define a schema to store data in CouchDB. CouchDB is a project of the Apache foundation emerging as one of the good modern non-sql database solutions. Let's define a Pet document using couchdbkit:

>>> from formalchemy.ext import couchdb
>>> from couchdbkit import schema
>>> class Pet(couchdb.Document):
...     name = schema.StringProperty()

What about the form ? Here it is:

>>> fs = FieldSet(Pet)
>>> fs.bind(Pet())
>>> print fs.render()

So easy.

Why couchdbkit and not couchdb-python ? Don't know. I guess it's doable with couchdb-python too. The only reason is the same as Jean Sarkosy's potential election at the Epad's presidency. I know Nicolas, HAHA. No. I know Benoît Chesneau (aka benoitc). Benoît release some good stuff related to CouchDB both in python and erlang. Have a look to his bitbucket account.

Using zope.schema

I came from the zope world so I know zope.schema. Most python coders are afraid by the zope word. But they are wrong. At this time we can say that zope is no longer a framework but a set of well tested and well documented libraries. So let's define a small schema:

>>> from zope import interface
>>> from zope import schema

>>> class IPet(interface.Interface):
...     name = schema.TextLine(u'name')

Now we need an object to store values:

>>> class Pet(object):
...     interface.implements(IPet)

Let's use FormAlchemy to render a form for this pet:

>>> from formalchemy.ext.zope import FieldSet
>>> fs = FieldSet(IPet)
>>> fs = fs.bind(Pet())
>>> print fs.render()

That's it. We (at Alterway) use it in a customer project based on repoze.bfg and zope's ZODB as backend. It just work.

Using RDFAlchemy

RDFAlchemy define schemas to describe a RDF node. I know really nothing about RDF but implementing a FormAlchemy extension to support RDFAlchemy was easy so it's now in FormAlchemy. It's tagged as experimental but it work AFAIK.

One of the first implementation I like to have is a FOAF profile editor using FormAlchemy's RESTController (see bellow). I don't know how hard it can be but this can be awesome.

Pylons CRUD interface

I love Pylons. Just because it's simple and have full WSGI support. FormAlchemy have a pylons extensions for a while to generate an admin UI ala Django. This was cool but not perfect. I've added a new module in FA's pylons extension to allow to generate RESTFul CRUD interface based on a data model. Data model mean all models supported by FormAlchemy.

At this time I assume that this work with SQLAlchemy and couchdbkit's models. So I guess it's also usable with RDF stuff. I will try soon.

There is two controllers: RESTController and ModelsController. RESTController render a CRUD interface for a single model. ModelsController render an admin UI for all models found.

This is highly customisable. You just need to change one template.

Have a look at the documentation to read more about that.

fa.jquery

fa.jquery is a standalone package that provide a set of widgets based on jquery.ui. Have a look at the demo page. It also have a plugin registry to allow you to write your own widgets with a few lines of javascript.

You can change the default jquery.ui theme (redmond) and use your own. jquery.ui provide a theme editor

Shabti

Shabti is a set of pylons templates initiated by Graham Higgins. There is now a FormAlchemy template in Shabti to quick initialize a pylons project with FormAlchemy and fa.jquery. The template also initialize a CRUD interface in the admin controller for you.

Here is some screenshots of the admin UI using fa.jquery:

User listing:

http://www.gawel.org/thumbs/blog/shabti_users.png

User edit form:

http://www.gawel.org/thumbs/blog/shabti_user_edit.png

Notice that at this time Shabti require pylons-dev.

An now...

So what future for FormAlchemy ? This is not discussed yet but I like to reduce the amount of code. This mean using external dependencies.

FormAlchemy have a helpers.py module which mostly came from WebHelpers so I guess we can remove it and use WebHelpers instead.

FormAlchemy's validation stuff is simple but FormEncode is popular and powerful so it can be a good thing to use it for validation stuff.

I also like to add some pylons related stuff in fa.jquery to improve the CRUD interface. For example adding some ajax stuff to allow to add new record from a relation widget and maybe inline editing.

Last thing. At this time I'm the only contributor. Alex and Jonathan don't have time to contribute or are involved in other projects. If you like to contribute you can fork the FormAlchemy repository on bitbucket and use the pull request feature to submit patches. (Google code still to be the official repository) But please, FormAlchemy is a well tested library so run the tests before patch submission and be sure that your changes will don't break anything. Well tested patches are always welcome. Thanks !

That's it for now. Hope you're enjoyed it.