[Zope3-dev] Important IFile bug!

[Roger Ineichen]

Ok I see...

> -----Original Message-----
> From: Jim Fulton [mailto:jim at zope.com] 
> Sent: Monday, January 17, 2005 12:58 PM
> To: dev at projekt01.ch
> Cc: zope3-dev at zope.org
> Subject: Re: [Zope3-dev] Important IFile bug!
> 
> 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


And the class File looks like:

Class File(Persistent):

  implements(IFile, IMime)

  def __init__(self, data='', contentType='', encoding=''):
      self.data = data
      self.contentType = contentType
      self.encoding = encoding


or:

Class Mime(Persistent):

  implements(IMime)

  def __init__(self, data='', contentType='', encoding=''):
      self.data = File(data)
      self.contentType = contentType
      self.encoding = encoding



Can you give me some hints about what stores what?



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

Regards
Roger Ineichen

Projekt01 GmbH
www.projekt01.ch
_____________________________
END OF MESSAGE