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

[Jim Fulton]

Roger Ineichen wrote:
> 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.

This would be a feature change, not a bug fix.


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