[Zope3-dev] Important IFile bug!

Roger Ineichen dev at projekt01.ch
Sun Jan 16 21:21:10 EST 2005


 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?

Or can we Implement IMime with the attribute
contentType?

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.

This is directly backward compatible.
Where should we store the encoding? In a attribute
encoding of the File class? 
Or via a attribute annotation, for backward compatiility 
reason?

Or what do you mean with the interface IMime?


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. 
Sure, just if the contentType is not explicit set in the form.

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.

And if we don't wana show the content type field in the form,
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.

> - text area if content type is text/* *and* if an encoding
>    is specified.

That's the part of the File data widget.

> - entry of content type and, for text types, the encoding

That's the part of the ContentType widget.

> > The validate method of this field should allowes to store 
> > String and FileChunk? Others?
> 
> The validate method should accept strings and objects
> with read methods.
> 
> > Is there a python lib for reading files and find the 
> > content type like stefan was implementing for images?
> 
> Of course, in the unlikely event that the client sends the
> file type and/or encoding with the file upload, you should
> use that information.  Otherwise, use zope.app.content_types,
> which seems to use the Python mimetypes module.
> 
> If you feel especially inspired, it would be nice to store
> file-upload data in a session if someone submits a form
> with a file-upload using other than the main submit
> button or if there are validation errors on other fields.
> IOW, it would be cool if the widget stored the data in a
> session so that the data wasn't lost on a redisplay.

Yes

Reagrds
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
> 



More information about the Zope3-dev mailing list