This was from a couple of weeks ago:

We've kicked around the idea of an ExternalFile object, and I started a small project that fizzed out. My question was where to draw the line, do we make it a simple pipe to one file, or a Folderoid object that 'mounts' a part of a filesystem into Zope? The first would be pretty simple, the second would be pretty hard, IMO.

I wasn't ready to answer this the first time around. :^) What I am trying to do right now is to map URL entries built from a database query which builds an index table and include content located in the filesystem. Constraints are that the document URL appear to be a static URL (no GET query) and that I provide a unique DMTL wrapper for each folder which allows one to customize the wrapper that contains the filesystem-based data. Actually, I would like to obtain the included data from anywhere I need, not just from the filesystem. Now I know how to use pluggable brains from ZSQL to specify a class to get close to this, but what if the document isn't in the database and a query can't return it? I would like to have that same class behavior which would allow me to use a __getitem__ to use the 'filename' (which doesn't really exist anywhere) as info on how to include the content I need. I wrote a little external method - include_file() which takes the pathname from a folder attribute and the 'filename' which is called via a 'wrap' dtml method (wrap?filename) which includes the filedata in context. But instead of 'wrap/?filename' what I want is more like 'get/wrap/filename' where get sets the class behavior that knows how to find 'filename' and 'wrap' is the editable dtml in that folder which encapsulates it. Or I'd be very happy with 'wrap/filename', but I don't know how to assign __getitem__ behavior to a DTML document. :^) Alternately, I was thinking of writing a Product which allowed me to specify the dtml wrapper as an attribute and used a __getitem__ method to retrieve the filedata and encapsulate it in the wrapper. Suggestions? Thanks Kent