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

[Jim Fulton]

Stéphane Brunet wrote:
> Jim Fulton wrote:
> 
>>
>> First, you are confusing schema definitions and widgets.  You should
>> start from the definitions of the field types.
>>
> That was a typo... Sorry for the confusion :-P
> 
>> As Derrick (sort of) suggested, Bytes fields are fields that contain
>> Python strings, as opposed to Text fields, which contain unicodes.
>> Bytes values can contain pretty much arbitrary string values.  For
>> example, a Bytes fields could contain image data.
>>
>> ASCII fields contain only 7-bit ascii data. ASCII fields were introduced
>> in recognition that many Bytes fields were being used in cases of source
>> code where the desire was, mainly, to avoid unicode.
>>
> I see! I have just found the definition of ASCII fields which are 
> derivatives of Bytes field but with a validate function (for the 0-127 
> range).
> Even if ASCII can be stored in Bytes field, the choice has been made to 
> separate the two types of fields in order to add this validation 
> function. Right ?

Right

>> There are lots of schemas that are using Bytes that should probably
>> use ASCII or Text instead.  I would say that most or all occurrences
>> of BytesLine should use ASCIILine instead. Unfortunately there is no
>> ASCIILine. Sigh.
>>
>> The widgets are probably out of sync with these definitions.
>> I suspect that the Bytes widgets behave the way they do because
>> they were developed before we had an ASCCII type.
> 
> 
> If I try to sum up a little bit what I understand :
> * concerning fields :
>    - Bytes field should be used for raw binary data or byte-friendly 
> text encoding (e.g. UTF-8) _except ASCII_.

Right

>    - BytesLine field should be used for byte-friendly single-line text 
> encoding (e.g. UTF-8) _except ASCII_.

Well, It's hard for me to believe that someone *really* wants to specify a type
that can contain more or less arbitrary binary data except for
a newline.  I don't really think we need BytesLine.

>    - ASCII field should be used for multi-line ASCII text.
>    - ASCIILine field for single-line ASCII text( e.g. MIME content type 
> field in the "File" package), which must be added in zope.schema

Yup

> * concerning widgets :
>    - ASCIIWidget should be preferred to BytesWidget because its name 
> clearly informs about the expected text encoding (although 
> Bytes(Area)Widget accepts only ASCII text).

Widget names don't matter.  The widget names should match the
field names.

IMO, the default widget for a bytes line should be a file-upload widget.

>    - ASCIIAreaWidget should be added in order to replace BytesAreaWidget 
> for multiline ASCII fields.

Yes

>    - The need for Bytes(Area)Widgets is just unclear in my mind...

Good. ;)  I see no point in such a thing. An upload widget should be
used instead.

>>
>> It woul dbe great for someone to try to get this cleaned up. :)
>>
> I would be ready to put some work on it as soon as everything is clear 
> in my mind about the use of Bytes v.s. ASCII fields and 
> Bytes(Area)Widgets. Moreover, this is related to the issue 302 which I 
> am trying to solve (the job is almost done concerning the encoding 
> problems).

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.

I don't know what your solution looks like at this point. But I'll note:

- File objects store Bytes data.  Not unicode.

- For text content, File object's want to keep track of an
   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.

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