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:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to