[Zope3-dev] Re: IFile, widget, form etc

[Jim Fulton]

Roger Ineichen wrote:
> Hi Janko, Jim, ...
> 
> Perhaps we should think about the problem a little bit 
> befor we implement something. Or at least sync our ideas.
> 
> The result should give us a proposal.
> 
> Here are some questions I have.
> 
> -------------------------------
> Reimplement the IFile
> 
> The File has to handle different parts.
> 
> - The file data itself.
> - The content type

No.  The file object should have a field
of typr mime. *That* field should hold
that data, mime type and encoding, for text
types.


> - The filename (stored in the parent IContainer)

What file name? The name that the file was uploaded from?
I don't see why we would need that.

As far for the name within the zope container, I see no reason
while files need to no the name they are stred under.

> ...
> 
> For the implementation zope3 offers us the following components:
> 
> - IFile (interface)
> - IField (schema field)
> - File (class)
> - XYWidget (widgets)
> - Add and edit/upload forms
> - Events
> - Perhaps adapters and views
> 
> 
> Let's define the problems and find out what's the right 
> component for the implementation
> 
> 
> Problem 1 (content type)
> 
> What's happen if we add a file object called filename.txt.
> What's the content type of this object?

If the clinet supplied a content type (and encoding), we use
what the client provided.  Otherwise, we use the value given by
zope.app.content_types.  In any case, we allow the user to override
the value.


> What's happen if we upload a binary object like a ms-word document?
> Does the content type change?

Yes.

> Who is responsible for the content type if we rename the object?

The content type does not depend directly on the name.
The content type changes *only* when:

- a new value is uploased, or when
- the user explicitly edits the content type (and possibly encoding)

> Should the content type change if we rename the fielname to
> filename.xsl?

No

> Or should the content type change if we upload a new file called
> filename.js?

Yes

> 
> Problem 2 (i18n)
> 
> Can we implement the same pattern of "Problem 1" in a i18n implementation?

I have no idea what you are asking.

> One restriction is, that the fielname of a i18n file is given for all
> languages. How does the content type work on i18n implementation.
> Perhaps we have to implement a validation for preventing upload
> different content types on each language.

I don't follow the above at all.

I'll note again that the file type depends only loosely
on file extensions.

> -------------------------------
> 
> My main target is an implementation which works for normal and 
> i18n files.

i18n files are only demonstrations.

 > It should also work with the standard form framework.

Yes

> Own implementation should work if we inherit from IFile or from
> the IFile (field) out of the box.

I don't know what this means.

> BTW
> I have added some i18n add and edit forms in our framework
> for supporting IFile with i18n support. Perhaps we can move
> this forms to Zope3.

Internationalization of content is out of scope for Zope 3.
I'm happy to see samples of how it might be handled checked in,
however, there are too many ways to handle i18n of content to
make it a core feature of the application server.

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