[Zope3-dev] FTP/PUT/file-system-reprentation progress

[Casey Duncan]

On Friday 07 February 2003 06:22 pm, Tres Seaver wrote:
> On Fri, 2003-02-07 at 12:20, Jim Fulton wrote:
> >=20
> > Hi,
> >=20
> > This is to provide an update on some work I've been doing getting FTP=
,
> > PUT, and, eventually, WebDAV working.
> >=20
> > As far as I know, FTP is now working. I think that there are some cas=
es
> > where error handling isn't quite right. If you see anything, please l=
et
> > me know.
> >=20
> > 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 WebD=
AV,
> > which uses many additional HTTP methods.
> >=20
> > I've ripped out the old VFS framework, which was way too Unix file-sy=
stem
> > 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=20
you
> > who lobbied for more commonality accross these should be happy. :)
> >=20
> > I also changed the site-management objects to provide simple browsing
> > interfaces to facilitate combined browsing and editing with tools lik=
e
> > Mozilla Composer, Amaya, and WebDAV tools.
> >=20
> > I'd like to describe a scenario (using old terminoligy, I'm afraid)
> > that illustrates a part of what I'm trying to achiev.
> >=20
> > 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:
> >=20
> >    /++etc++Services/Packages/default/folder
> >=20
> > 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:
> >=20
> >    /somefolder/someotherfolder/v1.html
> >=20
> > and see the view.
> >=20
> > I could also browser to:
> >=20
> >    /++etc++Services/Packages/default/folder/v1.html
> >=20
> > 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.
> >=20
> > Note that no source port was needed (nothing up my sleeve ;).
>=20
> Heh, you performed a "magician's force" there:  you *know* that you wan=
t
> the source, because you are publishing the template in a special place:=
=20
> it is delineated differently, but you still have a "funny" URL.  You do
> get away (here, anyway) with running only one HTTP publisher.
>=20
> > 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:
> >=20
> >    /somefolder/someotherfolder/v1.html
> >=20
> > will return the template rendered for someotherfolder.
> >=20
> > We still need file-represntation adapters for a few more content type=
s,
> > like dtml pages and sql scripts.  These would make good small project=
s
> > for some one. :)
>=20
> 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 piec=
e
> 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 th=
e
> 'document_src' protocol....nah, that's a pipe dream. :)
>=20
> Tres.

Maybe if we didn't cram presentation and template logic in the same space=
 we=20
wouldn't have this problem... ;^)

working-on-alternatives-ly yr's,

-Casey=20