[Zope] ftp editing methods

[Phillip J. Eby]

At 09:31 AM 6/29/99 -0400, Michel Pelletier wrote:
>
>> Amos@digicool.com (Amos Latteier) writes:
>> > This has been discussed before. There should probably be some better
>> > system for sniffing uploaded content and trying to figure 
>> out what sort
>> > of Zope object to create. This could be based on
>> > 
>> >   * file extensions
>> >   * http headers
>> >   * the content of the uploaded object
>> >   * Zope preferences
>> > 
>> > This is a fairly complex problem. For example, there should 
>> be some way
>> > for you to specify that uploaded files with a given file extension
>> > create instances of a given Z Class.
>
>This is an interesting proposition, granted, automated FTP tools
>probably wouldn't understand to use the command set we set up.  For
>tools like Emacs however, we could hack the existing lisp code, and
>command line tools the user could just use the interface straight up.
>
>> Another idea would be to make it possible using site exec to set a
>> flag, whether or not the files are up- and downloaded with or without
>> HTTP-Headers. Then it would be possible, to set a Content-Type
>> Header. And I would find it extremely useful, if I could set
>> Attributes in those headers too, because I often have documents, which
>> need a standard set of attributes and it would be nice, if it were
>> possible to edit them together with the content.
>> 
>
>This is possible, I don't know how hard it would be to impliment.  It
>would also involve up coming up with a few of our own Content Types.

A way that I solve a similar problem in my ZPublisher-based application
engine, is for container-ish things to have a "ClassMaps" attribute (which
is a cumulative multimapping of its parents' ClassMaps, plus its local
mapping) that maps file name fragments to class information.  When I need
to know the type of a file, I look up:

* The entire filename plus '/' if it's a directory (or a MKCOL/MKDIR type
operation)
* The filename as is
* The longest possible file extension (e.g. ".tar.gz" before ".gz"), with a
trailing /, if applicable and then without.
* Successively shorter file extensions, with and without the /

Proceeding until a match is found.  This approach lets me do things like
make an entry for "CVS/" so that CVS directories are automatically assigned
an appropriate class, and I can distinguish between a name or extension
used for a file vs. the same used for a directory.

Of course, I'm using this to access an actual filesystem rather than to
handle FTP/WebDAV.  And in Zope this would be further complicated by the
need to manage content types.  Last, and worst (from my POV anyway), is
that Zope has no way to drop off the extensions so that URL's can remain
polymorphic (i.e., an object's name has nothing to do with its
type/implementation).  In my file-driven engine, object id's do not include
the file extension but are resolved polymorphically.  If foo.html becomes
foo.dtml, the URL is still 'foo' and no part of the system really cares
except that object's implementation.

Of course, Zope could use the multimapping approach in the opposite way
from how I do it, and instead ADD the filename extensions when operating in
FTP/WebDAV mode.  So 'foo.sql' in that mode is really 'foo' in regular Zope.

But I'm probably just muddying the water further at this point, so I'll
shut up now.  :)