On 7/16/07, Kevin Horn <[EMAIL PROTECTED]> wrote: > I think that this would get pretty ugly in a web app, though it would > probably work. > Here are the problems I see: > - has to run on Windows (TG performs much more slowly on Windows in my > experience) > - overhead of importing win32all/pywin32 (a fairly large package) > - memory usage would go through the roof, at least if this was a commonly > accessed feature > - COM stuff is a pain to debug > - you don't have much control over when the COM object is actually > destroyed/released by Python, not sure if this would be a problem in > practice, though > - have to learn to Word/Excel object models > > Like I said though, it should work if you can't find a better solution, but > I prefer to restrict COM to the desktop app and batch processing arenas.
Agreed, I did this from a web app before, but we used a multi-process solution where the web app made a call to the report creation process over HTTP, and got back a URL which could be given to the client. And actually there was more trickery to it than that because we found it way easier to use VBA to script word, so while we initiated the process via a COM call to word, most of the work was done in word by VBA scripts, which pulled data out of a Python COM server. Not something I would recommend! Unless of course, you need something that can't be done with reportlab. --Mark --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
