Code

Opened 9 years ago

Closed 9 years ago

#585 closed task (fixed)

[Document] - Render your Django's data with specialized applications

Reported by: paolo <paolo@…> Owned by: adrian
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: UI/UX:

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!

Attachments (0)

Change History (3)

comment:1 Changed 9 years ago by adrian

  • Owner changed from Adrian to adrian
  • Status changed from new to assigned

Thanks very much for taking the time to write this up! I'll work on integrating it.

comment:2 Changed 9 years ago by abeusher

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 Changed 9 years ago by adrian

  • milestone Version 1.0 deleted
  • Resolution set to fixed
  • Status changed from assigned to closed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.