Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Creating temperory files for a web application

1 view
Skip to first unread message

koranthala

unread,
May 8, 2009, 5:26:36 AM5/8/09
to
Hi,
I am doing web development using Django. I need to create an image
(chart) and show it to the users - based on some data which user
selects.
My question is - how do I create a temporary image for the user? I
thought of tempfile, but I think it will be deleted once the process
is done - which would happen by the time user starts seeing the image.
I can think of no other option other than to have another script which
will delete all images based on time of creation.
Since python is extensively used for web development, I guess this
should be an usual scenario for many people here. How do you usually
handle this?

Diez B. Roggisch

unread,
May 8, 2009, 5:49:41 AM5/8/09
to
koranthala wrote:

> Hi,
> I am doing web development using Django. I need to create an image
> (chart) and show it to the users - based on some data which user
> selects.
> My question is - how do I create a temporary image for the user? I
> thought of tempfile, but I think it will be deleted once the process
> is done - which would happen by the time user starts seeing the image.

What makes you think that? You are the one creating it, you are responsible
for deleting it.

> I can think of no other option other than to have another script which
> will delete all images based on time of creation.
> Since python is extensively used for web development, I guess this
> should be an usual scenario for many people here. How do you usually
> handle this?

There are various solutions - tempfiles, files based on a criteria (e.g.
username and image-properties) so that they don't pollute the harddrive.

For both approaches cleaning up as you suggest might be needed.

Alternatively, if you use sessions, you can use memory-cached images.

Or you can use the database.

But the cleaning-up might get necessary here as well.

The cleanest solution would be if the image would be rendered on the fly,
based on GET-parameters (or REST-ful urls) so that you can render it into
memory as string, but then forget immediately about it.

Diez

koranthala

unread,
May 8, 2009, 8:22:44 AM5/8/09
to

Thank you Diez.
I would like to go ahead with the cleanest solution indeed.
I am creating the image on the fly. But I could not understand what
you meant by render to memory as a string.
How do we send the image to the browser?

Were you mentioning about having the image as a string and then
passing to the browser based on data URL scheme <RFC 2397> ?
Or is it something else like XBM format or something? I am sorry - but
I am quite unsure of what you meant?

I am actually creating PDFs, CSVs and images on the fly. So, I need to
delete them all after that.
The images can be somewhat large - ~2MB. The RFC mentions that large
data cannot be sent that way.

Is it that I will have to delete the images using a separate script
later?

koranthala

unread,
May 8, 2009, 8:38:44 AM5/8/09
to

Hi Diez,
I think I understood your point now.
Is it ?
(1) Have a separate URL for the image - update urls.py for that
(2) Pass all the GET parameters to that URL again.
(3) Recalculate the fields again in that URL
(4) Create the image and send back as image/png based on the
received fields.
Other than the fact that I will be hitting the DB twice - for the
fields in the original URL and for creating Image in the second URL, I
think this is the best option.
Please let me know whether I have understood correctly.

The same option can be done for CSV and PDF files too. Thank you
very much Diez.

Diez B. Roggisch

unread,
May 9, 2009, 10:13:20 AM5/9/09
to
>
> Hi Diez,
> I think I understood your point now.
> Is it ?
> (1) Have a separate URL for the image - update urls.py for that
> (2) Pass all the GET parameters to that URL again.
> (3) Recalculate the fields again in that URL
> (4) Create the image and send back as image/png based on the
> received fields.
> Other than the fact that I will be hitting the DB twice - for the
> fields in the original URL and for creating Image in the second URL, I
> think this is the best option.
> Please let me know whether I have understood correctly.
>
> The same option can be done for CSV and PDF files too. Thank you
> very much Diez.

Yep, that's what I meant.

Diez

sserrano

unread,
May 17, 2009, 6:34:37 PM5/17/09
to
I would use a js plotting library, like http://code.google.com/p/flot/
0 new messages