[Zope3-dev] IFile refactoring

[Roger Ineichen]

Thanks for answering

> -----Original Message-----
> From: zope3-dev-bounces+dev=projekt01.ch at zope.org 
> [mailto:zope3-dev-bounces+dev=projekt01.ch at zope.org] On 
> Behalf Of Fred Drake
> Sent: Monday, January 24, 2005 7:58 PM
> To: dev at projekt01.ch
> Cc: zope3-dev at zope.org
> Subject: Re: [Zope3-dev] IFile refactoring
> 
> On Mon, 24 Jan 2005 16:52:54 +0100, Roger Ineichen 
> <dev at projekt01.ch> wrote:
> > The contents attribute on IFile is a Mime instance.
> 
> So far so good.
> 
> > I didn't implement the IMime interface in the File
> 
> That's fine too.
> 
> > class directly. If we whould do so, we have to
> > provide the schema part of IMime. (data, mimeType, encoding)
> > as properties.
> 
> Not clear that this necessarily follows.
> 
> > I think the IFile should only provide:
> > 
> > contents = Mime
> > get/setMimeType()
> > get/setEncoding()
> > open()
> > getSize()
> 
> This isn't what's on the branch.  

You mean we have also the properties
- data
- contentType
in the File class. 
This is just for backward compatibility.

Or what do you exactly mean?

> The get/set methods (the IReadMime
> and IWriteMime interfaces) should go away; there's no need to provide
> methods in addition to normal fields.  There's also no need to have
> the data field since we have to have the open() method anyway.  We've
> generally moved away from accessors in favor of properties.

Don't we need a 'data' property for the form framework (Mime.data)?
Or can we handle method fields? 
Or just use a different interface for to map the open method 
to a property for the editform and addform views?


What's excactly the API from the File class?

> I'm a little confused about what the IMime fields speciify; more
> detailed documentation is required.  Some specific questions:
> 
> - Does the mimeType field include only the major/minor 
> portion of the type, or
>   should arbitrary type parameters be part of that as well?  If this
> is only for the
>   major/minor, then there's no place for type parameters.  
> One example where the
>   type parameters are interesting is the content type "text/plain;
> format=flowed";
>   many others are defined on a type-specific basis.
> 
> - The separation of encoding as a field is something to be careful
> about.  It's not
>   always possible to tell whether the type is textual using 
> only the major/minor
>   type.  It's also worth noting that the "charset" parameter isn't
> exactly the same
>   as the encoding, and encoding may be determined from the 
> content body in some
>   cases if there's no charset parameter on the type (think 
> about XML encodings).
> 
> I expect that some additional properties would be helpful:  major and
> minor would be nice to be able to access directly, and some way to get
> a parameter value would be good to have.  Parameters could be exposed
> as a mapping object, for instance.

Ok, I'm not a expert for the encoding part.
Is there a good way to support all usecases?

Please can you add some hints about encoding on the proposal
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/IFileRefact
oring
 

Regards
Roger Ineichen

> 
>   -Fred
> 
> -- 
> Fred L. Drake, Jr.    <fdrake at gmail.com>
> Zope Corporation
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: 
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
> 
>