Roger Ineichen wrote:
Behalf Of Jim Fulton
Sent: Monday, June 13, 2005 8:39 PM
To: Stéphane Brunet
Subject: Re: [Zope3-dev] Re: Existential questionabout
BytesWidget v.s. ASCIIWidget
Stéphane Brunet wrote:
Jim Fulton wrote:
I don't know what your solution looks like at this point. But
- File objects store Bytes data. Not unicode.
- For text content, File object's want to keep track of an
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.
Yes, that's correct. I recommend to start a new branch and
take over the correct parts from jhauser trunk. I implemented
some recommended changes but never finished it because I don't
know a way how we can support backward compatibility.
I can take time next week for working at the trunk and check
Philipps Widget changes and help with the IFile refactoring.
I also like to move our i18n implementation wit local Negotiator
etc. to the trunk if it's Ok. I will add a i81n branch if I'm
ready with this.
Whould be nice if somebody or you Jim can give me more advice about
the migration path for such a IFile refactoring.
I think it is too late to do this for 3.1.
I believe that Stephan is planning on trying to release the first beta
in the next couple of days.
At this point, before doing anything major, I'd like to wait for Blobs
to land in ZODB and then create a *new* file content type. I suggest
avoiding backward-compatibility issues by creating a new file type.
For the existing file type, perhaps we can just:
- Collect an encoding on the upload form that is required if the
content type is text/* and is not allowed otherwise.
- Always use this encoding to encode edit forms and thus assume
that we get this encoding when edit forms are submitted.
Maybe this is even too much to do for 3.1.
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