Hi +1 on this except that I use xlrd and xlwt to read and write Excel files. To generate the excel file I just generate a list of lists (an array effectively) and pass that through a function which walks the list and generates the excel worksheet that I write to a StringIO so it can be returned to the client.
François On Oct 2, 2013, at 6:34 AM, Jirka Vejrazka <jirka.vejra...@gmail.com> wrote: > Hi Thomas, > > I'm doing exactly this - allowing users to download (graphically simple) > XLSx files from my web app, it also needs to be available for download weeks > later. > > As Russell pointed out, you don't need to store data on this if you have a > way of getting the same set of data later, you can always regenerate the same > Excel file. You don't even need to use StringIO for that. > > I'm using the save_virtual_notebook() in openpyxl package to generate the > Excel file straight from database upon each (infrequent) request. > > HTH > > Jirka > > > On Wed, Oct 2, 2013 at 9:36 AM, Russell Keith-Magee <russ...@keith-magee.com> > wrote: > > On Wed, Oct 2, 2013 at 2:33 PM, DJ-Tom <eventel...@gmail.com> wrote: > Hi, > > this is quite easy to answer - those reports need to be archived - users must > be able to download them days or weeks later. > > So I will create a record in a database for each report that is created so > users can access it later - maybe this can be seen as "uploading" a file to > the server that acts as a document repository, with the only difference that > the file is not uploaded, but produced by the server. > > Well, if you need archival, there are two alternatives: > > 1. Write the file to disk at the same time it is being generated. There's no > reason you have to serve the file from where it was generated -- generate it, > write it, and serve it. > > 2. Make sure the report will always be generated the same way. An analog here > -- if you request a page from a web server, it probably isn't saved on disk > like that (unless it's a genuinely static page) -- the server knows how to > reproduce the same page every time you request a specific URL. Make the > reports the same -- if you request /report/September-2013, you generate the > same report every time. > > The second approach depends on whether you have well time-bucketed data, but > it's certainly possible to do. > > I don't see how I could use the xlsxwriter object in the way it is described > here https://docs.djangoproject.com/en/1.5/howto/outputting-pdf/ - how could > I pass the httpresponse object to xlsxWriter? > (Maybe I have not yet found how this might work - but it is not what I need > anyways...) > > I haven't used xlsxwriter myself, but the key part of the PDF example is that > StringIO is an object that adheres to the python File API, but doesn't > actually involve a file. So, you open a StringIO object, "write" to it, then > dump the contents as the HTTP response. > > So - whatever API endpoint on xlsxwriter lets you pass in a file object -- > pass in a StringIO instance instead. > > Yours, > Russ Magee %-) > > > > Thomas > > Am Mittwoch, 2. Oktober 2013 02:11:21 UTC+2 schrieb Russell Keith-Magee: > > On Tue, Oct 1, 2013 at 9:49 PM, DJ-Tom <event...@gmail.com> wrote: > Hi, > > I need to create database report downloads in Excel format (via xlsxwriter) > and I'm wondering if there is any standard or best practice as to where those > downloads should be located. > > Especially helpful would be if there was a portable way of managing the file > system location and web request url in a way so that I don't have to change > settings between the development and production server. > > Is this -> https://docs.djangoproject.com/en/1.5/topics/files/ the way to go? > > If they're sever generated, why do they need to hit the file system at all? > > The following example in the docs: > > https://docs.djangoproject.com/en/1.5/howto/outputting-pdf/ > > shows how you can stream a report directly to the end user. The example uses > reportlab to produce a PDF, but the same approach will work for a tool > writing to a different format. > > Yours, > Russ Magee %-) > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/93413618-01d4-4fc0-a4d0-94fa67efe371%40googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAJxq84-kJ%2BNhxt43b_ighenWZGErpHvPRE3q53BGrDczckFPyg%40mail.gmail.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAFhEBEARVBt%3DQMavyq3gt8XaVXvmmeAH_CKT3jcyPS2e8h8MTQ%40mail.gmail.com. > For more options, visit https://groups.google.com/groups/opt_out.
signature.asc
Description: Message signed with OpenPGP using GPGMail
