Stphane 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. Wa. 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-1714http://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
