[Zope3-dev] FTP/PUT/file-system-reprentation progress
Tres Seaver
tseaver@zope.com
07 Feb 2003 18:22:33 -0500
On Fri, 2003-02-07 at 12:20, Jim Fulton wrote:
>
> Hi,
>
> This is to provide an update on some work I've been doing getting FTP,
> PUT, and, eventually, WebDAV working.
>
> As far as I know, FTP is now working. I think that there are some cases
> where error handling isn't quite right. If you see anything, please let
> me know.
>
> I also have HTTP PUT working. This required adding the foundation for any
> non-browser HTTP method. (Browser methods are GET, HEAD, and POST.
> BTW, I also implemented HEAD.) This foundation will also support WebDAV,
> which uses many additional HTTP methods.
>
> I've ripped out the old VFS framework, which was way too Unix file-system
> specific and replaces with a simpler, I think adapter framework that is
> based on mimimal file-system representatin ideas.
> See zope.app.interfaces.file. This framework supports FTP and PUT and will
> play a part in object-system <-> file-system synchronization. (Those of you
> who lobbied for more commonality accross these should be happy. :)
>
> I also changed the site-management objects to provide simple browsing
> interfaces to facilitate combined browsing and editing with tools like
> Mozilla Composer, Amaya, and WebDAV tools.
>
> I'd like to describe a scenario (using old terminoligy, I'm afraid)
> that illustrates a part of what I'm trying to achiev.
>
> As a site developer, I can create a view sub-package in a site's
> default package. A view sub-package is a folder that can only contain
> templates. When you add a template to the view sub-package, it
> automatically registered as a view using configuration parameters
> defined in the subpackage as a whole. Suppose my subpackage
> is named "folder" and is configured so that it's templates are
> configured to be views for IFolder. The path to the view package is:
>
> /++etc++Services/Packages/default/folder
>
> I can visit that path with an FTP client and save a zpt source
> file, named v1.html. Someone can then visit a url like:
>
> /somefolder/someotherfolder/v1.html
>
> and see the view.
>
> I could also browser to:
>
> /++etc++Services/Packages/default/folder/v1.html
>
> with Mozilla, or Amaya to view the template source as an
> html document. I can choose to edit the document with
> Mozilla Composer. When I save my changes, they are written
> back and reflected in the views.
>
> Note that no source port was needed (nothing up my sleeve ;).
Heh, you performed a "magician's force" there: you *know* that you want
the source, because you are publishing the template in a special place:
it is delineated differently, but you still have a "funny" URL. You do
get away (here, anyway) with running only one HTTP publisher.
> The reason that a GET of
> /++etc++Services/Packages/default/folder/v1.html
> will always return the source of the template, while a GET of:
>
> /somefolder/someotherfolder/v1.html
>
> will return the template rendered for someotherfolder.
>
> We still need file-represntation adapters for a few more content types,
> like dtml pages and sql scripts. These would make good small projects
> for some one. :)
Since the "magician's force" isn't going to be available for objects in
content space, we are still stuck here: how is the GET view for a piece
of content going to know whether to render the object or not? Sniffing
HTTP_AGENT is a strategy Chris and Fred have been experimenting with
for Zope 2.7, but it is still tricky. If WebDAV clients implemented the
'document_src' protocol....nah, that's a pipe dream. :)
Tres.
--
===============================================================
Tres Seaver tseaver@zope.com
Zope Corporation "Zope Dealers" http://www.zope.com