[Zope3-dev] Important IFile bug!

[Jim Fulton]

Roger Ineichen wrote:
>  Hi jim
> 
>>-----Original Message-----
>>From: Jim Fulton [mailto:jim at zope.com] 
>>Sent: Friday, January 14, 2005 5:30 PM
>>To: dev at projekt01.ch
>>Cc: zope3-dev at zope.org
>>Subject: Re: [Zope3-dev] Important IFile bug!
>>
>>Roger Ineichen wrote:
>>
>>...
>>
>>
>>>Ok, what can I do?
>>>
>>>Should I implement a IData field and enhance this field?
>>
>>I think you should define an IMime schema that defines methods
>>to get and set the data. I suggest that this should be a
>>file-like interface, with, at least, read and write.
>>It should have a mime-type attribute and an encoding
>>attribute, for use with text.
>>
>>Then you should define a mine field (IMImeField/MimeField)
>>for data with this interface.
> 
> 
> This whould mean we change the IFile implementation?

IFile should be changes to use a mime field.

> Or can we Implement IMime with the attribute
> contentType?

We should define a mime data type and provide a field
and widget to support it.

> like:
> 
> class IMime(Interface):
> 
>   contentType = BytesLine(
>         title = _(u'Content Type'),
>         description=_(u'[...].'),
>         default='',
>         required=False,
>         missing_value=''
>         )
> 
> class IFile(IIMime):
> 
>   data = FileData(*) (
>         title=_(u'Data'),
>         description=_(u'[...]'),
>         default='',
>         missing_value='',
>         required=False,
>         )
> 
> (*)The field FileData will replace the 
> Bytes field and validate Bytes and FileChunk.

No

class IMime(Interface):

     data = ...

     contentType = ...

     encoding = ...

class IFile(Interface):

    def open(mode='r'):
        # return a file-like object for reading or updating the
        # file value

    # For backward compatibility, a deprecated data attr
    data = ... # as is now

> This is directly backward compatible.
> Where should we store the encoding? In a attribute
> encoding of the File class? 

The encoding should be stored as part of the mime value.
It might be better to make the cntent type itself
a structured value ans store the encoding as part of that.
But I think it would be fine to just put this on the mime
value.  Of course, the encoding only applied to text types.

> Or via a attribute annotation, for backward compatiility 
> reason?

There is no backward compatibility consideration for encoding.


> Or what do you mean with the interface IMime?

I mean we define a data type for dealing with mime bodies.
This data type stores the data and the type information (mime
type and encoding).

> Then we can add a widget which works with session
> and reads the contentType from the filename via the session
> of the file data upload. 

The mime type only comes from a file name after other
avenues have been exhausted.  The clients *can* provide the mime
type as part of the uploaded data.

So:

1. Get the content type from file-upload meta data, if provided by
    the client. (The same applied to PUT.)

2. Use zope.app.content_types

3. Use whatever the user provides.  In any case, don't attenpt
    to change the type on a rename.

> Sure, just if the contentType is not explicit set in the form.

Right

> The widget part:
> 
> We implement the mechansim for guess the contentType
> in a ContentTypeWidget. The missing filename for guessing the 
> contentType could be red from the session.

Any data provided with the upload, including file name, should
be stored in the session.  Or, the guessing could be done when
the file is first uploaded, and *that* could be stored in the session.
After the initial upload, if the form is redisplayed, we could show the
giessed value and let the user override it.

> And if we don't wana show the content type field in the form,

Why wouldn't we want to show it?

> but also guess it,
> we can use a hidden input widget for read the content type
> via the filename form the session and store it to the file object.
> 
> 
> 
>>Finally, you need a widget.
>>
>>The widget should support:
>>
>>- file-upload
> 
> 
> That's the part of the File data widget.

It should be part of the mime widget

> 
>>- text area if content type is text/* *and* if an encoding
>>   is specified.
> 
> 
> That's the part of the File data widget.

It should be pat of the mime widget

> 
>>- entry of content type and, for text types, the encoding
> 
> 
> That's the part of the ContentType widget.

It shoud be part of the mime widget

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