Andy McKay wrote:

Oliver Bleutgen wrote:

...

I'm looking for a product which allows me to manage files in zope which reside on the filesystem, and provide a natural way to be served from apache. As far as I see, none of LocalFS, ExternalFile, ExtFile provide a way to do that naturally - for instance by providing the 'precondition' property (to raise an appropriate redirect) or to allow an definable <a href="<something"> string to be rendered when called, analogous to the Image object.

Im not sure what you mean, LocalFS is all about managing FS things from Zope.

Perhaps you might mean something like FS Cache Manager which takes objects served from and puts them on the File System in cache to be served from the FS using Apache, and works great for File and Image objects. http://www.zope.org/Members/andym/FSCacheManager

Thanks for the answer, and sorry for not being clearer, but I not quite sure myself how to really accomplish what I want. What I need is: 1) Files shouldn't be stored in the zodb 2) Files should be managable (delete, create, update) from zope 3) Files shouldn't be served from zope 4) No additional administration outside apache is needed. The products I mentioned accomplish 1), 2) and 4). They can accomplish 3), but only if users always remember to link to these files in a "special" way, i.e. with a different path than they would link them if they were normal zope objects. FS Cache Manager accomplishes 3) (at least well enough for me), but not 4), while I wouldn't mind 2 lines in httpd.conf. That's why I thought about a product like LocalsFS which would just - instead of delivering the file when it's called from the web - raise a redirect to an appropriate URI where then apache would serve the file. cheers, oliver

Stefan H. Holek wrote:

Some time ago I have modified ExtFile to allow for 3) as well. And now I've even published it ;-).

<http://www.zope.org/Members/shh/ExtFile/>

Cool, open source development on demand ;), nice! One question though, from the description I gather that you have overriden ExtImage's tag method, have you also modified ExtFile's __call__ method (or whatever causes the serving of the file content, haven't looked at the source)? If not, are you interested in a patch? (Ok, two questions). I need that functionality for files, not images, and think that returning a redirect with mangling in EXTFILE_STATIC_PATH would do the trick. Tell me what you think, and I'll try to make that a bit more customizable if you want to incorporate it. cheers, oliver

Hi all, There should be a really simple solution to the problem I'm facing, but want to make sure if the solutions I'm considering are viable ones. I'm designing a shopping cart product. A complete rewrite of its PHP counterpart, which makes use of MySQL as backend. Basically the PHP version uses the following MySQL tables to categorize products and present them to users accordingly: - a category description table: all categories go into this table - a product description table: all descriptions of purchasable products go into this table - a category-product mapping table: the table tells us which product belongs to which category. It **allows** a product to get associated with **multiple** categories. Well, guess it'll be easy to implement the first two tables as objects in Zope. The problem arises from the fact that we should be able to put a product object into multiple category folderish objects without actually **duplicating** it: if a product goes under the Categories A and B and when we delete the product from its parent Category A, it should be also deleted from the Category B. The same logic should also apply when we modify the object. It's much like creating a reference to an object instead of actually deep-copying it when we copy a product from one category to another. I thought about putting all product objects into a single root category ( self-catalogging and BTreeFolderish ) and make subcategories transparent: /Bookstore - root category /aBook - a product object /Thriller - subcategory ( transparent folderish ) /Romance - subcategory ( transparent folderish ) /Romance/Sheldon - sub-subcategory (transparent folderish, will this nested subcategories work? not sure. ) We can visit the aBook object taking advantage of acquisition: - /Bookstore/aBook - /Bookstore/Thriller/aBook - /Bookstore/Romance/aBook - /Bookstore/Romance/Sheldon/aBook Will this work without any problems? What would be the easiest way to implement this? ( Without relying on RDBMS like MySQL , of course :-) Any hints or comments would be greatly appreciated. Cheers, Wankyu Choi --------------------------------------------------------------- Wankyu Choi CEO/President NeoQuest Communications, Inc. http://www.zoper.net http://www.neoboard.net ---------------------------------------------------------------

Thanks for your feedback :-)

Notes on this: Transparent Folders are not needed for this to work as you describe below. Aquisition is a natural property of folderish objects in Zope. What's special about Transparency is that their contents look like they're in the folder's parent. (This might allow you to organize your objects but make them available on the lower level.) Transparent Folders are known performance issues, however.

Just wanted to organize objects using folderish containers but not actually putting them into the folders. Did some research and found that what I want to do would be much like Shane's Symlink. I didn't mean to use Transparent Folder **product** :-) Guess I should have used the terms symbolic links or hard links.

...

Will this work without any problems? What would be the easiest way to implement this? ( Without relying on RDBMS like MySQL , of course :-)

You can do this as long as you're not relying on folder contents to find content.

Indeed, I need to rely on folder contents. They should act as that third MySQL table holding category_id-product_id key pairs.

A few approaches to consider: <snip>

Tought using folders would make life a lot easier. If not, I'd rather reuse those MySQL tables :-) I plan to use CMF but want to avoid using Topics. ( I already have more than 3,000 products being sold using that PHP shopping cart. Need as light an approach as possible. ) I just didn't want to use a URL like 'http://www.yourmall.com/describe_item?item_id=1010&category_id=Thriller" as the PHP version does. http://www.yourmall.com/Thriller/1010 looks and will work neater. Guess I'll try Shane's Symlink and see if it works fine with CMF. My initial try caused an error with CMF's skinning machinery. Again, thanks for your input. --------------------------------------------------------------- Wankyu Choi CEO/President NeoQuest Communications, Inc. http://www.zoper.net http://www.neoboard.net ---------------------------------------------------------------

Oliver Bleutgen wrote at 2003-4-7 15:10 +0200:

... Thanks for the answer, and sorry for not being clearer, but I not quite sure myself how to really accomplish what I want. What I need is:

1) Files shouldn't be stored in the zodb 2) Files should be managable (delete, create, update) from zope 3) Files shouldn't be served from zope 4) No additional administration outside apache is needed.

The products I mentioned accomplish 1), 2) and 4). They can accomplish 3), but only if users always remember to link to these files in a "special" way, i.e. with a different path than they would link them if they were normal zope objects.

I use an Apache Rewrite Rule (maybe via a RewriteMap) to do that. If the URL matches a "localFS", then the RewriteRule fires and serves the request directly from the file system. Of course, there is some administration when new "localFS" instances are created. It might be an even better idea, just to put a cache before Zope and do not worry about (occational) serving by Zope.... Dieter