[Zope3-dev] Re: Existentialquestionabout BytesWidget v.s. ASCIIWidget

[Roger Ineichen]

Hi Jim

Behalf Of Jim Fulton
> Sent: Monday, June 13, 2005 11:21 PM
> To: dev at projekt01.ch
> Cc: zope3-dev at zope.org
> 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: zope3-dev at zope.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.

Regards
Roger Ineichen

> 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
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: 
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
> 
>