Behalf Of Jim Fulton
> Sent: Monday, June 13, 2005 11:21 PM
> To: [EMAIL PROTECTED]
> Cc: email@example.com
> Subject: Re: [Zope3-dev] Re: Existentialquestionabout
> BytesWidget v.s. ASCIIWidget
> Roger Ineichen wrote:
> > Hi Jim
> > Behalf Of Jim Fulton
> >>Sent: Monday, June 13, 2005 8:39 PM
> >>To: Stéphane Brunet
> >>Cc: firstname.lastname@example.org
> >>Subject: Re: [Zope3-dev] Re: Existential questionabout
> >>BytesWidget v.s. ASCIIWidget
> >>Stéphane Brunet wrote:
> >>>Jim Fulton wrote:
> > [snip]
> >>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.
> > 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.
Ok, could be a alternative.
> - 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.
Yes, I didn't think about the 3.1 release. It's better to do this
after the release. But perhaps we can do a 3.1.1 after the new
IFile is implemented. Remember the IFile is still broken on
large uploads since the beginning because we use FileChunk instances
for storing on a BytesField. Since we use a own View for upload
file data and this view doesn't follow the form framework standards
(no validation) there is no problem with this. I think.
> 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 mailing list