[Zope3-dev] Re: Existential question about BytesWidget v.s. ASCIIWidget

[Jim Fulton]

Stéphane Brunet wrote:
> Jim Fulton wrote:
> 
>>
>> Oh, that. Waaaaa.  Christian Theune almost had this fixed last year
>> at EuroPython.
>>
>> This is also related to a File object refactoring that someone *almost*
>> finished recently.
> 
> 
> What kind of refactoring ? Is it already in the trunk ?

No,

   http://svn.zope.org/Zope3/branches/jhauser-filefieldwidget/

Note that this happened before the recent (PyCon) Blob work.
Ii also doesn't reflect a number of comments I made
a few months back.

>>
>> I don't know what your solution looks like at this point. But I'll note:
>>
>> - File objects store Bytes data.  Not unicode.
>>
> I did not changed anything to the IFile interface. Text or not, the 
> content is always stored on the Bytes field.
> 
>> - For text content, File object's want to keep track of an
>>   encoding.
>>
> This is not what I understood of the description of issue 302 on 
> Collector (see 
> http://mail.zope.org/pipermail/zope3-dev/2004-October/012371.html ).
> 
> My solution just convert the text input to UTF-8 before for storage in 
> the Bytes field. A UTF-8 specific widget (very similar to the future 
> ASCIIAreaWidget) is used in the edit form. When the text file is 
> displayed, the content is converted to unicode and afterwards to the 
> preferred encoding of the user's browser. This works quite well on my 
> computer...

This may be an improvement over what we have now.  Howeverm you can't
count on UTF-8 in general.  The content may have been uploaded, in which
case you really don't know what the encoding is unless someone tells you.

You have no idea what the prefered encoding of the user's browser is.
You *should* be able to control what encoding they send back by
specifying an encoding on the generated form.  If you specify the encoding,
then modern browsers should reliably send back the same encoding.

>> I expect that, in the long term (3.2?), we'll need to totally redo
>> Files to make then sane and to take advantage of ZODB Blobs.
>>
> Resolving issue 302 is on the todo list for 3.1.

Frankly, I don't think it should be a show stopper for 3.1.

 > However, one could take
> advantage of this future refactoring in order to merge I18NFile and File 
> into a single package. After all, a non-i18n file is just a i18n file 
> with a default language...

I think that would be a bad idea.  There are a number of possible approaches
to management of content translation.  Trying to make all files ne I18nFiles
would be too great a policy commitment.

> BTW, I18NFile is also broken because of encoding problems. I was not 
> able to enter non-ASCII characters in the text area... That's pretty 
> problematic for a I18N-aware product :-D

It is really just a demo. :/

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org