[Zope-CMF] Re: WebDAV MKCOL

[Tres Seaver]

seb bacon wrote:

> * Jeffrey Shell <jeffrey@Digicool.com> [010525 19:05]:
> 
>>I put some thoughts together on this a few months back, even made a 
>>tracker issue (that I later deferred) and put a proposal together 
>>that I probably should have put in the normal dev.zope.org 
>>fishbowl::
>>
>>http://cmf.zope.org/PTK/Members/jshell/FolderCreationProposal.txt
>>
> 
> from the above doc:
> 
> 
>>The risk involved with manage_addFolder hijacking is that it would
>>disallow completely the ability to create standard Folders inside of
>>a PortalFolder. 
>>
> 
> I think that the manage_MKCOL solution is a decent compromise.  It
> does involve hacking the ObjectManager and NullResource source, but
> doesn't hijack the existing folder method, thus avoiding any kind of
> assumption about the folder nature of a Collection in its semantics.
> A PUT_factory clone is uneccesary, IMO.
> 
> Is this the right place to have this discussion, or should it
> take place on the Tracker, or elsewhere?


This kind of discussion about changes to the Zope core is supposed
to be "fishbowled" via the "Proposals" mechanism at:

   http://dev.zope.org

In this case, we only need a small change to webdav.NullResource::

diff -u -u -r1.24.16.1 NullResource.py
--- NullResource.py	2001/02/15 19:23:14	1.24.16.1
+++ NullResource.py	2001/05/28 15:12:42
@@ -187,7 +187,10 @@
             raise 'Method Not Allowed', 'The name %s is in use.' % name
         if not hasattr(parent, '__dav_collection__'):
             raise 'Forbidden', 'Cannot create collection at this location.'
-        parent.manage_addFolder(name)
+        import pdb; pdb.set_trace()
+        mkcol_handler = getattr( parent, 'MKCOL_handler'
+                               , parent.manage_addFolder )
+        mkcol_handler(name)
         RESPONSE.setStatus(201)
         RESPONSE.setBody('')
         return RESPONSE


I prefer this over the inheritance-based solution because it allows
the site manager to configure the policy differently for different
locations (and it is a smaller patch, as well).  I've just tested the
patch on a stock 2.3.2 Zope with CMF from CVS;  I used a PythonScript
for the handler::

## Script (Python) "MKCOL_handler"
##bind container=container
##bind context=context
##bind namespace=
##bind script=script
##bind subpath=traverse_subpath
##parameters=name
##title=
##
context.invokeFactory( 'Folder', name )

Because this patch is so small, I have submitted it to the Zope
Collector:

   http://classic.zope.org:8080/Collector/2254/view


> 
>>On Friday, May 25, 2001, at 12:41  PM, Phillip J. Eby wrote:
>>
>>
>>>At 06:01 PM 5/25/01 +0100, seb bacon wrote:
>>>
>>>
>>>> - Perhaps a MKCOL_factory is more appropriate?  It'd be good to have
>>>>   some input on this.  I thought not because I simply couldn't
>>>>   envisage a scenario where one would want anything other than the
>>>>   current folder type to be created, but perhaps that's not a good
>>>>   enough reason...
>>>>
>>>Shouldn't this just be delegated back to some kind of 
>>>"manage_MKCOL" method on the original folder?  (Or is that what 
>>>you mean by MKCOL_factory?)  The default implementation of such a 
>>>method in ObjectManager could be to make a sub-folder.  
>>>Specialized containers could override it as they please, since I 
>>>can think of many instances where I would want to have a container 
>>>create a different kind of container for its child containers.
>>>
>>>So, if a "null" resource simply delegated this operation back to 
>>>the container it was spawned from, the container could make that 
>>>decision without having to have its own class of null resource.
>>>


-- 
===============================================================
Tres Seaver                                tseaver@digicool.com
Digital Creations     "Zope Dealers"       http://www.zope.org