On Wed, Dec 3, 2008 at 11:24 PM, Andi Albrecht
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Dec 4, 2008 at 5:37 AM, Jorge Vargas <[EMAIL PROTECTED]> wrote:
>>
>> On Wed, Dec 3, 2008 at 4:19 PM, Andi Albrecht
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> On Wed, Dec 3, 2008 at 2:56 PM, Jorge Vargas <[EMAIL PROTECTED]> wrote:
>>>>
>>>> On Tue, Dec 2, 2008 at 8:38 AM, Helio Pereira
>>>> <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> Hi all
>>>>>
>>>>> I have this in my controller to control all important downloads in
>>>>> tg2: http://paste.turbogears.org/paste/15338
>>>>> Is this the best way to do it?
>>>>>
>>>>> Many thanks for all,
>>>>> Helio Pereira
>>>>>
>>>> that works although you may want to take a look at paste.fileapp, as
>>>> it is more robust sending headers for modified and such. Here is an
>>>> example.
>>>> http://paste.chrisarndt.de/paste/99e8dbf02a4e4af5bd365ef722de2c69?wrap=no
>>>>
>>>> docs for fileapp are thin  http://pythonpaste.org/modules/fileapp.html
>>>> but if you look at the code it's far more robust than your custom
>>>> implementation. You may also want to take a look at DirectoryApp.
>>>
>>> hm, I've just worked on a similar controller today using TG1.0.X but I
>>> had two problems with the approach mentioned in the docs
>>> (http://docs.turbogears.org/1.0/FileUploadTutorial#add-the-download-method)
>>> which looks very similar to the example from above.
>>>
>> I don't have an answer but some comments.
>>
>>> The first thing is that the files I have to deliver are stored in the
>>> database and it looks like that both functions expect the file
>>> somewhere in the file system.
>> I have never liked that approach is there a reason for you to store
>> files in the db?
>
> I don't like it too, but the reason for this is quite simple: It's a
> legacy database and partially synced with another legacy database and
> both store files as blobs...
>
>>> I had a quick look at the CP sources and
>>> it seems that there's no handy function that sets proper headers when
>>> using file-like objects. I don't know the sources for fileapp, but
>>> according to the example above it should be similar.
>>>
>> I don't know about CP.
> sorry, I was talking about CherryPy
>
>>
>>> The other thing is more a question than a "real" problem. Shouldn't be
>>> the filename in the Content-Disposition header encoded according to
>>> RFC 2231 if it contains characters other than US_ASCII? AFAICT
>>> serve_file() don't handle that case, but at least I'm not sure if it's
>>> really required to follow RFC 2231...
>>>
>>> Does anyone know a convenient way to server files (possibly with
>>> non-US_ASCII chars in the file name) stored in a database with
>>> automagically good-looking headers for TurboGears 1.0?
>>>
>> This isn't a great idea, most systems/people know nothing about
>> unicode so sending files with non-us characters in their file name
>> isn't the best idea. it may confuse your users.
>
> That's an interesting point. I've made opposite experiences with my
> application which is focussed on a German speaking audience. Users
> complained about broken non-us characters when downloading files (of
> course, it was a Internet Explorer only problem as far as I could
> remember), even paraphrasing them e.g. with the two letter replacement
> for german umlauts was confusing.
>
I guess is a location thing, people in latin america aren't used to
seeing files with accents or ñ even though that's common in the
language, it may be a result of our lack of a decent IT community in
general or maybe just ignorance. But I can see how in german this is a
must, while in spanish is not that bad.

>>
>>> Andi
>>>
>>>>
>>>> >
>>>>
>>>
>>> >
>>>
>>
>> >
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to