[Twisted-Python] Serving files, again

[Mario Ruggier]

Thanks, I have played with your suggestions somewhat.
But, I want to avoid doing things such as overriding File's
render() as I had initially (File.render() does too many nice things
to throw away so easily, as pointed out in the other posts).

A source of confusion for me is knowing which,
and when, specific methods are called automatically.
Particularly, it would be nice to have a clarification (in the
API docs) of when the methods getChildForRequest() and
getChildWithDefault() are called -- they seem not be called in
a non-siteroot resource. Things worked well with PathArgs, it
being set as root resource, but for an arbitrary resource,
like the example I previoulsy included, the game seems to
change .

But, indeed, as Clark, I do find this model of cascading requests
very intriguing, and tantalizingly powerful...

Cheers, mario


> Anyway, I wanted to respond to your code below...
>
> | class RestrictedResource(resource.Resource):
> |     def isLeaf(self):
> |         return 1
> |     def render(self, request):
> ...
> |         fullPath = docsBase +'/'+ subPath
> |         try:
> |             if not os.path.exists(fullPath):
> |                 raise Exception # of type...
> |             elif os.path.isdir(fullPath):
> |                 dirlist = processDirlist(os.listdir(fullPath))
> |             elif os.path.isfile(fullPath):
> |                 import mimetypes
>
> This is interesting.  I would have probably done it a less
> efficient way (but perhaps more flexible)?  I would have
> used two resources, a DirectoryResource and a FileResource.
>
> The DirectoryResource would override getChild(path,request) and
> dynamically look for a child in the current path, leveraging the
> descent operation in getChildForRequest.  This object would then
> either return the subordinate NotFoundResource, DirectoryResource
> or a FileResource object depending on what the path matched.
> The constructor for these child resources would have a fullpath,
> constructed by concatinating the fullpath of the current Directory
> with the given path.
>
> The FileResource would serve up the given file, by overriding
> the render(request) method as you have specified above.  In this
> way one could provide a replacement FileResource or override a
> DirectoryResource, etc.
>
> If you wanted to get tricky, you could "stuff" the path state
> into the request object and the DirectoryResource could
> 'return self' instead of creating intermediary Directories.
> This leads to the following more general questions:
>
>   1.  There should be a general way to attach "resource specific"
>       data to a given request, for DirectoryResource it'd be the
>       current path, for PathArgs, it'd be the mapping of path
>       arguments to variables.
>
>   2.  This mechanism could thus be used for inter-resource
>       communication, say where a UserSession(FilterResource)
>       would attach a directive to "compress_files" or not
>       to subordinate FileResources.
>
> As I said in a previous post, I'm quite impressed with the
> whole "Resource" concept and the "tail recursive" descent
> mechanism provided via getChildForRequest.
>
> Hope this helps...