Unkillable zombie blog

Tools for generating PDFs from django.

For a Django project i’m working on i needed to generate PDF reports. For example a “job ticket” that displays the client data, the material list and a list of “processing” actions to be performed, or an invoice (classic use case).

What i wanted was a way to generate these PDF files from a template using Django’s templating language. I had previously done something similar using PISA but i was not satisfied. There documentation was rather bad, generating HTML/CSS is not my strong point and automatic tools produce unreadable code. It does work though.

After some heavy and masterful googling i came up with several options.

1. Reportlab. Very well known, very powerful, but the good parts are not free. I did not want to write the layout using Python code. I’d rather use some high level abstraction on top of Reportlab. Their RML framework (which does exactly that) seems great but as far as i can see it is not free. There are open source alternatives though, which i’ll talk about later.
2. Pod Uses OpenOffice in server mode to generate documents in PDF. I’ll be running my software in a memory limited VPS and running OpenOffice (even in server mode) seems very scary. I did not investigate the exact memory requirements though because it seemed like a waste of time.
3. rst2pdf. RST is very awesome, Sphinx uses it but from my reading of rst it seems that generating accurate and custom layouts seems somewhat difficult (for a report that needs specific elements in specific locations).
4. trml2pdf. This is a tiny and free implementation of RML. This seemed to be a better solution, but what i wanted was a way to generate RML documents using a GUI tool (i’m a lazy bastard). The solution is tiny_sxw2rml which produces an RML document from an OpenOffice .odt file.
5. JasperReports. This is a very impressive Java package and GUI designer that can generate beautiful reports from various data sources. This was a serious contender (** especially** with their very nice GUI designer) but i chose to avoid it because i could not use the Django ORM to do templating (i can use raw SQL but that is severely suboptimal in templating , especially on complex templates). I could use the Django ORM to produce an XML file with all the information but the prospect of using an XML file (using XPath ) seemed dreadful (but it would work nicely). It is a Java package with Python bindings available for it and a web interface that can be used to access it using a standard interface (HTTP)

The fourth solution (trml2pdf) is the one i chose. These tools are developed by the openerp framework for their reporting needs.

However, it is far from a perfect solution. There is no official repository for this package with various versions floating around the web with different features. More specifically, i was only able to use barcode generation using the version from openerp server source code, which i had to patch to make it work (because it relied on other modules of OpenERP).

Additionally, i had to patch it to make it work with unicode fonts as per the instructions from the OpenErp Docs. Not something you would want to depend on.

Nevertheless i was able to make it all work. I could use the tool tiny_sxw2rml to produce an rml template that would first be processed by the Django templating system and then fed into trml2pdf to produce a PDF. It works.

All in all i would have to say that JasperReports is the best solution from a technical standpoint since it has a great GUI designer that produces beautiful documents with perfect layout, has a lot of features, a large community, can be used as an independent server that produces PDF documents and much much more. The main problem is that you lose that advantage of integrating your workflow into the philosophy of Django (ORM/templates etc) and have to walk the extra mile.

I’ve already integrated trml2pdf but i’m keeping my eye open for a way to switch to JasperReports.

I’d like to hear what solutions others may have used/considered for this.

Django generic relations in test fixtures

Το Django framework περιλαμβάνει μια λειτουργικότητα που την ονομάζει content types. Το content types framework επιτρέπει, μεταξύ άλλων, στο Django να έχει λειτουργίες όπως τα generic relations

Ο τρόπος λειτουργίας είναι σχετικά απλός. Το content types framework βασικά λέει:

Για κάθε μοντέλο του ORM φτιάχνω μια εγγραφή στον πίνακα django_content_type που περιέχει ,μεταξύ άλλων, το όνομα του application και το όνομα του μοντέλου και φυσικά ένα ID.

Το generic relationship επιτρέπει σε ένα μοντέλο να έχει ένα foreign key σε ένα οποιοδήποτε άλλο μοντέλο στο django. Αυτό το επιτυγχάνει προσθέτοντας 2 πεδία στο μοντέλο που περιέχει το foreign key. Το content type και το id.

Έστω οτι έχουμε ένα μοντέλο Comment. Μιας και θέλουμε το Comment μπορεί να μπορεί να αναρτηθεί σε διάφορα μοντέλα (πχ Story, άλλα Comments, News, Product κλπ) χρησιμοποιούμε generic relations. Αν ονομάζαμε το πεδίο αυτό “commenting_on” τότε όταν ζητήσουμε απο το django να μας δώσει το object στο οποίο δείχνει το commenting_on, το Django θα δεί το content_type πεδίο, θα αναζητήσει την αντίστοιχη εγγραφή στον πίνακα django_content_types και θα βρεί το application και model στο οποίο αναφερόμαστε. Γνωρίζοντας αυτά, και αφού έχει και το id μπορεί έυκολα να μας επιστρέψει ένα instance του μοντέλου.

Εδώ πρέπει να αναφέρω μιά ακόμα τεχνολογία του django. Το serialization framework που μας επιτρέπει να κάνουμε serialize και να εξάγουμε τα δεδομένα μας σε αρχείο κειμένου (YAML,XML, JSON και άλλα) όπως και να τα εισάγουμε στην βάση μας απο ένα serialized αρχείο.

Τα serialization είναι εξαιρετικά χρήσιμο σε πάρα πολλές περιπτώσεις, με πιθανότατα πιο συχνή το Testing framework, όπου μας δίνει την δυνατότητα πριν απο κάθε test να φορτώνουμε κάποια γνωστά δεδομένα στην database.

Όταν κάνουμε serialize ένα μοντέλο που περιέχει generic foreign keys, οι serializers του Django απλά καταγράφουν το content_type_id και το object_id.

Εδώ δημιουργείται το πρόβλημα.

Τα content_types φτιάχνονται κατα το syncdb (κάτι που γίνεται στην αρχή του test runner ) και τα id που θα πάρουν εξαρτώνται απο την σειρά με την οποία θα διαβάσει τις εφαρμογές και τα μοντέλα το django. Τα test fixtures που φτιάξαμε νωρίτερα μεσω του serializer θα βγούν άχρηστα όταν για κάποιο λόγω αλλάξουν τα id των content types, και τα test μας θα αρχίσουν να σπάνε και χωρίς εμείς να ξέρουμε γιατί (αφού τα φόρτωσε χωρίς πρόβλημα).

Δυστυχώς δεν υπάρχει καλή λύση για αυτό το πρόβλημα.

Μια προσωρινή αλλα πολύ άσχημη λύση είναι στο test να κάνουμε lookup για το σωστό content type και να το αλλάζουμε on-the-fly. Yuck.

Είμαι γκαντέμης ή απλά άτυχος? :p

Τhe Alexandros Grigoropoulos’s Diary Release

Αν και σπανίως βλέπω τηλεόραση, έχω δεί οτι η υπόθεση με την δολοφονία του 15χρονου Αλέξανδρου Γρηγορόπουλου έχει γίνει διεθνώς είδηση.
Δεν είχα συνειδητοποιήσει, όμως, πόσο έχει επηρεάσει την διεθνή κοινότητα μέχρι που στο community (planet βασικά) του Django είδα να ονομάζουν την νέα release του diario blogging software με τίτλο “The Alexandros Grigoropoulos’s Diary Release”

Οπως αναφέρουν στο project :

This version is a tribute to Alexandros Grigoropoulos, 15-year-old boy, libertarian, murdered by greek police in last week (2008-12-06).

Συνήθως η προγραμματιστική κοινότητα είναι πολύ απομακρυσμένη απο την πολιτική/κοινωνική επικαιρότητα, και σίγουρα αυτή η πρακτική δεν είναι κάτι συχνό.

Ενδιαφέρον…

(Βέβαια εδώ έχουν σπάσει και κάψει το σύμπαν και εγώ περιμένω ένα release άγνωστου software για να καταλάβω τι έχει γίνει? Έκαστος στο είδος του :p )

Django CSRF tag for AJAX POST calls.

Το Django μας παρέχει (προαιρετικά) το CSRF middleware του οποίου η δουλειά είναι να αποτρέπει τις επιθέσεις CSRF. Για να το πετύχει αυτό, στα response object βρίσκει τις φόρμες με POST method και “εισάγει” ένα ακόμα κρυφό field που περιέχει ένα token μοναδικό για το session. Στα POST request επιβεβαιώνει οτι το token υπάρχει και είναι σωστό.

Όλα ωραία και καλά, αλλα αυτός ο τρόπος έχει το πρόβλημα ότι όταν θέλουμε να κάνουμε AJAX κλήσεις με POST requests δεν θα δουλέψουν γιατί το CSRF middelware δεν θα βρεί tokens.

Για να λύσω αυτό το πρόβλημα με τον πιό απλό τρόπο έφτιαξα ένα template tag που παρέχει ένα token στα template μου.

Έτσι, για παράδειγμα στο YUI όταν κάνω το request είναι κάπως έτσι:

1
2
3
4

{%csrf_token as token    %}
params = "ham="+ham+"&eggs="+eggs + "&csrfmiddlewaretoken={{token}}" ;
var transaction = YAHOO.util.Connect.asyncRequest("POST", {%url spam%},
    callback, params);

Μιας και βασίζεται στην ύπαρξη του sessionid στο cookie, αυτό το tag δεν θα μας δώσει token όταν ο χρήστης έχει απενεργοποιήσει τα cookies (κάτι που σπάει ένα σκασμό site οπότε δεν με πολυνοιάζει) και όταν είναι το πρώτο request στο site μας. (Μπορούμε όμως να ελέγξουμε αν υπάρχει το token και να πράξουμε κατάλληλα)

Ορίστε και το tag:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

from django.conf import settings
from django.utils.hashcompat import md5_constructor
import re

class CsrfNode(template.Node):
"""
Tag that provides a CSRF token in the context.
Usage: {% csrf_token as token %}
If the user has no cookies (cookies disabled, or this is
the first ever page view on the site, this tag will provide
an empty token. You can test that (eg to refresh the page)
"""

def __init__(self,var_name):
    self.var_name = var_name

def render(self,context):
    SESSION_COOKIE_NAME = getattr(settings,
            "SESSION_COOKIE_NAME","sessionid")
    sess_key = context['request'].COOKIES.get(SESSION_COOKIE_NAME,None)
    if not sess_key:
        # User has no cookie. Empty token.
        token = ""
    else:
        val = settings.SECRET_KEY + sess_key
        token = md5_constructor( val  ).hexdigest()
    context[self.var_name] = token
    return ''

@register.tag(name='csrf_token')
def do_csrf_token(parser,token):
    try:
        tag_name , params = token.contents.split(None,1)
    except ValueError:
        msg = "%r tag requires arguments" % token.contents.split()[0]
        raise template.TemplateSyntaxError(msg)
    m = re.search(r'^as (\w+)$', params)
    if not m:
        msg = "%r tag had invalid arguments" % tag_name
        raise template.TemplateSyntaxError(msg)
    var_name = m.groups()[0]
    return CsrfNode(var_name)

Ελπίζω να είναι bug free :p

Django tips (part 1)

Στην ενασχόλησή μου με το Django έχω κάνει πολλά λάθη και έχω μάθει με τον δύσκολο τρόπο (βλέπε “χτυπάω το κεφάλι μου στον τοίχο” ). Κάνω μια προσπάθεια λοιπόν να καταγράψω μερικά χρήσιμα tips που ελπίζω να κάνουν την ζωή σας λίγο πιό εύκολη η/και να αποφύγετε τα δικά μου λάθη

Pluggables

Πλέον, υπάρχουν πάρα πολλά pluggables για Django. Πριν ξεκινήσετε να γράφετε κάποια λειτουργικότητα , κάντε μια αναζήτηση να βεβαιωθείτε οτι δεν υπάρχει ήδη κάποιο pluggable που κάνει την δουλειά που θέλετε να κάνετε. Ένα site με αρκετά καλή συλλογή απο pluggables είναι το http://djangoplugables.com/.

Ένα pluggable που θα σας βοηθήσει πάρα πολύ , ειδικά στο debugging είναι το django-command-extensions που σας δίνει κάποια υπέροχα εργαλεία για να κάνετε την ζωή σας ποιό έυκολη. Κυρίως προσφέρει νέες εντολές για το manage.py.
Για παράδειγμα σας δίνει το shell_plus που κάνει αυτόματα import όλα τα μοντέλα σας (μεγάλη ευκολία) και διάφορα άλλα. Το σημαντικότερο όμως είναι οτι εαν έχετε εγκαταστήσει το Werkzeug τότε κάνει χρήση του debugger του, και στα traceback στον browser σας δίνει ένα καταπληκτικό AJAX console debugger. Για να δείτε το werkzeug τρέχετε:

./manage.py runserver_plus

(πάντα κάνω chmod +x manage.py για ευκολία )

named urls

Τα named urls είναι μια αντιστοιχία ονόματος (python string) με ένα URL. Αυτό σημαίνει οτι στα urls.py θα προσθέτεις την name=”myname” παράμετρο. Παράδειγμα:

1
2

url(r'^tag/(?P<tagname>\w+)/$','view_profiles_for_tag',
    name='profiles-for-tag'),

Προσέξετε οτι πλέον κάθε url pattern είναι το αποτέλεσμα της url() function και όχι απλά ένα tuple. Αυτό μας δίνει την δυνατότητα να χρησιμοποιήσουμε 2 πολύ σημαντικά εργαλεία. Την reverse() μέθοδο απο το django.core.urlresolvers και το {% url %} template tag. και τα 2 κάνουν την ίδια δουλειά, απλά η reverse() είναι χρήσιμη στα views (ή models) και το {%url%} στα templates. Η δουλειά τους είναι να βρούν το URL που θέλετε με βάση το όνομα (και τις παραμέτρους, αν το URL πάιρνει παραμέτρους).

Local settings

Μια ακόμα καλή πρακτική είναι που θα σας βοηθήσει πάρα πολύ στο deployment είναι να έχετε την εξής γραμμή στο τέλος του settings.py σας:

1

from local_settings import *

και να φτιάξετε ένα local_settings.py το οποίο θα το έχετε εκτός version control και στο οποιό θα μπορείτε να κάνετε override τιις ρυθμίσεις στο settings.py. Για παράδειγμα μπορείτε να έχετε άλλα paths (πχ για MEDIA_ROOT ) , άλλες ρυθμίσεις για DATABASE, για mail servers κλπ. Επιπλέον, στο settings.py μπορείτε να προσθέσετε το εξής στην αρχή :

1
2

import os.path
PROJECT_ROOT = os.path.normpath(os.path.dirname(__file__))

Με αυτό τον τρόπο έχετε μια μεταβλητή, το PROJECT_ROOT με το PATH του project σας. Μπορείτε τα υπόλοιπα paths να τα φτιάχνετε σχετικά με αυτή την τιμή αντί να τα κάνετε hardcode στο settings.py. Για παράδειγμα το TEMPLATE_DIRS μπορεί να είναι κάπως έτσι:

1
2
3

TEMPLATE_DIRS = (
    os.path.join(PROJECT_ROOT, 'templates'),
)

MEDIA_URL

Μια πρακτική που θα σας γλιτώσει απο μπελάδες είναι να χρησιμοποιείτε την MEDIA_URL μεταβλητή στα template σας.
Μπορεί σήμερα στον developement περιβάλλον σας να έχετε το MEDIA_URL="" αλλα άυριο στο deployment το πιθανότερο είναι να θέλετε να τρέχετε ένα media.myproject.com όπου θα σερβίρει τα media.
Σε αυτή την περίπτωση τα URL που θα έχετε γράψει στα template σας θα χρειάζονται αλλαγή.
Αυτό ισχύει για αντικείμενα όπως CSS ή εικόνες που δεν τις διαχειρίζεται το Django (οχι ImageFields δηλαδή). Στην περίπτωση τον FileField/ImageField υπάρχει το ειδικό attribute url που δίνει το σωστό url λαμβάνοντας υπόψιν του την ρύθμιση MEDIA_URL.
 Παράδειγμα:

1

<link rel="stylesheet" type="text/css" href="{{MEDIA_URL}}css/main.css" media="screen" />

RequestContext

Για να υπάρχει το MEDIA_URL διαθέσιμο στα template σας δεν αρκεί το κλασικό Context που περνάει το Django απο τα views στα templates. Χρειάζεστε το ειδικό RequestContext (που είναι subclass του Context). Το κλασικό Context στα view είναι κάπως έτσι:

1

return render_to_response('my_template.html',data_dict)

Για να περάσετε το RequestContext θα δώσετε ένα τρίτο argument στο render_to_reponse, ώς εξής:

1
2

return render_to_response('my_template.html', data_dict,
            context_instance=RequestContext(request))

To RequestContext ουσιαστικά λαμβάνει υπόψιν του την ρύθμιση TEMPLATE_CONTEXT_PROCESSORS στο settings.py και εκτελεί κάθε context_processor. ( ένα context processor, τροποποιεί το context που πάει στo template και εκτελείται σε κάθε request. Είναι κάτι σαν middelware.)
Υπάρχουν αρκετά default context processors αλλα είναι πάρα πολύ έυκολο να γράψετε το δικό σας, αν θέλετε κάθε template να έχει έξτρα μεταβλητές στο RequestContext που λαμβάνει.

Νέο software στο blog

Εδώ και μερικές ημέρες έχω αλλάξει το software του blog μου. Το προηγούμενο software το είχα γράψει εγώ, ήταν πολύ απλό και είχα αρχίσει να θέλω features που δεν είχα χρόνο και όρεξη να γράψω. Έτσι “βγήκα στην γύρα” για αναζήτηση blogging software που θα ικανοποιούσε τις ανάγκες μου.

Το νέο software είναι το byteflow , είναι γραμμένο σε Django. Το byteflow έχει πολλά χαρακτηριστικά, αλλα αυτά που εγώ ήθελα κυρίως είναι:

• Να υποστηρίζει τουλάχιστον μια Lightweight Markup Language. Το να γράφεις τα post σε Markdown αντί για HTML είναι πολύ σημαντικό. Επίσης οι WYSIWYG editors δεν με βολεύουν γιατί βγάζουν απαράδεκτη HTML γεμάτη με HTML entities. Ειδικά στα Ελληνικά κείμενα δεν διαβάζεται η HTML.
• Syntax Highlighting σε τμήματα που περιέχουν κώδικα. Το byteflow δεν υποστηρίζει ακόμα syntax highlighting αλλα είναι παρα πολύ εύκολο να προστεθεί αυτή η δυνατότητα για κείμενα με markdown σύνταξη. Το έφτιαξα μόνος μου. Θα ακολουθήσει post με λεπτομέρειες για αυτό.
• Pingbacks

Πέρα απο τα features που ήταν σημαντικά για εμένα , το byteflow έχει αρκετά ακόμα features όπως:

• threaded comments
• Σωστή διαχείριση των χρηστών (το πρώτο comment ισούται εγγραφή, έχεις λογαριασμό, κλπ κλπ)
• Υποστήριξη Gravatar
• Captcha ( και ReCaptcha ) support
• OpenID
• Themes (Η δημιουργία theme θα πρέπει να είναι σαφώς ευκολότερη απο κάποια γνωστά PHP πακέτα αφού το Django χρησιμοποιεί μια πολύ απλή templating γλώσσα και δεν έχει PHP/SQL/HTML/Whatever ανακατεμένα σε ένα αρχείο.)
• Κάνει import απο το wordpress.
• Javascript preview στα comments και απάντηση στο comment που θές (απαραίτητο αφού είναι threaded τα comments)
• Στα φιλτράρισμα με βάση τα tags υποστηρίζει σύνολα (intersection με + και union με το |). Για παράδειγμα, αν θέλουμε όλα τα posts που έχουν τα tags django και greek: http://kill9.eu/tag/django+greek/ , ενώ αν θέλουμε όλα τα posts που έχουν τα tags django ή greek τότε: http://kill9.eu/tag/django|greek/ Με τον ίδιο τρόπο φτιάχνουμε και feeds. Πολύ χρήσιμο feature. Κάποιος μπορεί να θέλει μόνο άρθρα σε Django που είναι γραμμένα στα Ελληνικά. Απλά ζητάει το intersection των django και greek tags.
• Και άλλα πολλά όπως ένα προαιρετικό WYSIWYG editor (που μάλιστα μοιάζει ενδιαφέρον αλλα δεν πρόλαβα να τον εξερευνήσω ακόμα) , XFN , κλπ.

Αν και έγραψα scripts για να κάνω μεταφορά της database απο το παλιό στο καινούργιο, δυστυχώς τα comments δεν μπορούσα να τα μεταφέρω χωρίς να ενοχλήσω όσους είχαν σχολιάσει στο παρελθόν (μιας και είναι υποχρεωτική η εγγραφή τώρα, στέλνει email με επιβεβαίωση) Θα προσπαθήσω να τα προσθέσω όταν κάποιος κάνει σχόλιο στο μέλλον (και φτιάξει προφίλ δηλαδή).

To byteflow αναπτύσσεται ενεργά και η εγκατάστασή του είναι εύκολη. Υπάρχουν μερικά bugs και κάποια απο τα default themes δεν δουλεύουν σωστά.

Διαθέσιμο και το source code για το gentoo-users.org

svn checkout http://genmap.googlecode.com/svn/trunk/ genmap

Ξεκίνημα του www.gentoo-users.org

Πριν λίγο ανέβασα το www.gentoo-user.org.
Είναι ένα google maps mashup όπου οι χρήστες της διανομής Gentoo μπορούν να γραφτούν και προσθέσουν την γεωγραφική θέση τους.

Μπορείτε να δείτε τους πλησιέστερους χρήστες σε εσάς (με χιλιομετρική απόσταση) να δείτε το προφίλ τους και γενικά είναι μια προσπάθεια να δούμε που υπάρχουν κοινότητες (η να δημιουργηθούν!).

Το site δουλέυει με Django με χρήση του contrib.gis (GeoDjango). Τρέχει στο slicehost, σε διανομή … Gentoo :p

Ελπίζω να κάνω και διαθέσιμο μέσω open source άδειας τον κώδικα σύντομα.

The eagle has landed

• Refactored ORM. Με προσθήκη inheritance, και πολλά νέα κόλπα.
• Newforms. Το νεο σύστημα των forms που αντικαθιστά το παλαιό.
• Νέο Admin βασισμένο στο newforms
• GeoDjango. Το Γεωγραφικό framework για Django υπάρχει πλέον σαν contrib στο django.contrib.gis
• Βελτιωμένη υποστήριξη unicode
• Αυτόματο escaping στις μεταβλητές στα templates. Προσθέτει ασφάλεια σε XSS attacks.
• Νέα διαχείριση των αρχείων (και uploads). Πλέον είναι pluggable. Θες τα uploads να πηγαίνουν απευθείας στο S3 Amazon storage? Κανένα πρόβλημα
• Νέο django.contrib.comments. Το παλαιό έτσι και αλλιώς ήταν undocumented γιατι θα άλλαζε. Η αλλαγή έγινε και έχουμε και documentation.

Django trunk update