Opened 19 years ago
Closed 19 years ago
#585 closed task (fixed)
[Document] - Render your Django's data with specialized applications
Reported by: | Owned by: | Adrian Holovaty | |
---|---|---|---|
Component: | Documentation | Version: | |
Severity: | normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
This ticket regards Adrian's comment at this page:
http://www.djangoproject.com/documentation/outputting_pdfs/
I hope you can find the document useful in some way. Feel free to use it as you
want, if you want. It has been a pleasure to do something for you, in each case.
======================================================= Render your Django's data with specialized applications ======================================================= Django is brilliant for what concerns data-centric web applications. It offers an elegant solution to fill the distance that divide your data and users interested in them. It provides an object-to-relational mapper for easily retrieve data from the backend (actually PostgreSQL, MySQL, SQLite, more to come); an URL dispatcher to make you able to tailor URLs as you desire; a cache system to enable super-fast responses to queries; an admin interface automatically generated, commonly used for immediate prototiping and a lot of other great features. It faces another aspect that nowadays results very important from every perspective: Django also lets you exactly decide *how* to *present* data to the user. By default it prompts code that web browsers are able to understand, even if it is *not* the only code it is able to output. It is instead possible to output any kind of code, interpretable from different external applications. Demanding the rendering of your data to specialized applications, means that you can stop to abuse of web browsers to present information that instead would be better represented with other specific tools. The concept of 'views' make it is possible. Views, as the name suggests, provide the solution for organize your data in some format recognizable from some application. An excellent idea is to use views to adapt your data structure in a format that Open Office Writer can read and understand. Probably you know that Open Office documents *are* composed by *XML documents*. If you look inside an .odt (Open Document Type) document with unzip, you'll see XML files. Especially one of them is quite relevant: content.xml. At a first look it might seem ugly, but after some cosmetic improvement via 'xml.dom.minidom' Python module you can obtain a very well pretty printed version of it ('toprettyxml'). Once that you know that this file stores all the contents and layouts you have previously "drawn" in OOWriter, or OOCalc or one of other Open Office applications, it becomes natural to think to use this source file (generated *for free* when you save the Open Office document) as a model for the presentation of your data. You *will* fill this model with your data. Actually this is pretty easy in Django. You can load this XML file as a template, and then use the constructs provided by the template language (Django's one, Zope Page Template, and probably others as well) to fill the template with your data, repeat some sections, use conditions or whatever you need to satisfy your presentational needings. Once the code inside the view has rendered the template filling your data in it, it is sent to the visitor's browser saying that this response has to be viewed using a particular application instead of the browser itself: Open Office Write. This translates in adding the 'application/vnd.oasis.opendocument.text' mimetype to the response object. At this point, user's browser will recognize the mimetype and will invoke Open Office Writer passing to it the XML file representing the rendered template. OOWriter will read this XML and interpret it, generating the layout specified via XML, along with your data properly formatted. This is all what you need to do. Using the same simple concepts exposed in this brief document you can rely on the most of other external applications able to accept data in some known format; for example, Adrian Holovaty has written an interesting article about outputting PDFs with Django. It contains code too. Read it, it's worth it!
Change History (3)
comment:1 by , 19 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 19 years ago
Paolo,
Excellent article! I appreciate your vision for how Django can be used as a flexible framework for serving up multiple content types (not just html and xml!).
I think the concept of having users receive dynamically generated OpenOffice documents on the fly is mindblowing! I've done lots of Microsoft development in the past, so I am quite familiar with using VBA to create / manipulate dynamic COM objects (documents). With Django & OpenOffice dynamically generated business documents are now possible across the Internet. Wickedly cool'''
On the flip side, it might be interesting to experiment with serving up PDFs of dynamically generated OpenOffice documents. http://www.skynet.ie/~caolan/Fragments/ooo-cgi.html provides an interesting starting point.
Cheers,
Abe
comment:3 by , 19 years ago
milestone: | Version 1.0 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Thanks very much for taking the time to write this up! I'll work on integrating it.