Looking for variation of ExternalFile product
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. Is there something like that out there? thanks, oliver
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 -- Andy McKay
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
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/> HTH, Stefan --On Montag, 07. April 2003 15:10 +0200 Oliver Bleutgen <myzope@gmx.net> wrote:
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.
-- Those who write software only for pay should go hurt some other field. /Erik Naggum/
Stefan H. Holek wrote:
Some time ago I have modified ExtFile to allow for 3) as well. And now I've even published it ;-).
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
Should work with files too, yes. The method for ExtFiles is called link(). There also is a static_url() method that will return the Zope or static URL depending on whether EXTFILE_STATIC_PATH is set. It's not clear to me why you want to redirect though. The idea is to write URLs with static paths into your links and tags. ExtFile.index_html() will always return the file's content via Zope. I currently think this is good, and it seems necessary for b/w compatibility anyway. Try <tal:tag replace="structure file/link" /> or <a tal:attributes="href file/static_url" tal:content="file/title"> </a> Stefan On Montag, Apr 7, 2003, at 19:19 Europe/Vienna, Oliver Bleutgen wrote:
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 ---------------------------------------------------------------
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. )
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.
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 :-)
You can do this as long as you're not relying on folder contents to find content. A few approaches to consider: - use CMF and make your categories Portal Topics on some metadata. (One of the newer implementations, though, as the original is said to be killer slow.) - use regular Zope and catalog queries on a custom attibute (of metadata) for your categories. - use maxm's Relation product, or possibly Portable Hole, a similar product. - you might also put all your objects on a low level and look at them through acquisition, as you describe. I would probably make categories folderish objects that filter what they acquire. --jcc
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 ---------------------------------------------------------------
(This is a reply to the top post, which I can't get to ATM.) For an analogous task, where I had to realize 1:n relations, I did the following: - Create a custom folderish class ("ProductsFolder") with a ZCatalog (or derived from zcatalog), holding - in your case - the products (which are also custom objects). - Products have a tuple-like property "category_ids" - Create a class "Category" The instances of Category get a special random attribute "magic_id" on instanciation, long enough to practically guarantee uniqueness. The products are catalog aware and register with the zcatalog in the folder, which stores the property category_ids in a keyword index. Now products can be associated with a category by adding the category's magic_id to the property category_ids of that product. I use simply ZopeFind to locate all categories for the user interface of the editors, because this operation doesn't happen very often. The advantage is that this should scale quite well, for added speed you could use a BTree for the ProductsFolder. You also can move/create categories anywhere you want, they always will act the same (hold the same products) as long as they can "see" the ProductsFolder. HTH, oliver
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
Oliver Bleutgen wrote at 2003-4-4 19:57 +0200:
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
I is not natural that you want a Zope precondition for an object you do not want to serve by Zope ;-) Dieter
participants (6)
-
Andy McKay -
Dieter Maurer -
J Cameron Cooper -
Oliver Bleutgen -
Stefan H. Holek -
Wankyu Choi