Hello, I am not sure if this should go to zope-dev list, but I am rather a newbie in Zope and Python, and maybe just do not see something what is very obvious for Zope gurus :) This is what happened: after I fetched a CVS version of Zope, I noticed that Squishdot object became broken (it works on 2.1.6) with message: Squishdot Import Traceback Traceback (innermost last): File "/zope/lib/python/OFS/Application.py", line 387, in import_products product=__import__(pname, global_dict, global_dict, silly) File "/zope1/lib/python/Products/Squishdot/__init__.py", line 128, in ? import Squishdot, Squishfile File "/zope1/lib/python/Products/Squishdot/Squishdot.py", line 131, in ? from SearchIndex.TextIndex import TextIndex File "/zope/lib/python/SearchIndex/TextIndex.py", line 217, in ? from Lexicon import Lexicon, query, stop_word_dict ImportError: cannot import name query and (funny) there are really no "query" defs in Lexicon.py, only "query_hook" (so it is not a problem of Suishdot, but of SearchIndex)... Isn't it a bug in new SearchIndex or I just have to study some big thick Python book? :))) Vitaly.
Oops, seems like somebody already solved this problem some days ago (and it's a pity that squishdot will not work on CVS version) http://classic.zope.org:8080/Collector/1158/view ----- Original Message ----- From: "Vitaly Osipov" <vos@telenor.cz> To: "zope list" <zope@zope.org> Sent: Friday, April 07, 2000 3:26 PM Subject: [Zope] CVS version of Zope and Squishdot
Hello,
I am not sure if this should go to zope-dev list, but I am rather a newbie in Zope and Python, and maybe just do not see something what is very obvious for Zope gurus :)
This is what happened: after I fetched a CVS version of Zope, I noticed that Squishdot object became broken (it works on 2.1.6) with message:
Squishdot Import Traceback Traceback (innermost last): File "/zope/lib/python/OFS/Application.py", line 387, in import_products product=__import__(pname, global_dict, global_dict, silly) File "/zope1/lib/python/Products/Squishdot/__init__.py", line 128, in ? import Squishdot, Squishfile File "/zope1/lib/python/Products/Squishdot/Squishdot.py", line 131, in ? from SearchIndex.TextIndex import TextIndex File "/zope/lib/python/SearchIndex/TextIndex.py", line 217, in ? from Lexicon import Lexicon, query, stop_word_dict ImportError: cannot import name query
and (funny) there are really no "query" defs in Lexicon.py, only "query_hook" (so it is not a problem of Suishdot, but of SearchIndex)... Isn't it a bug in new SearchIndex or I just have to study some big thick Python book? :)))
Vitaly.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Vitaly Osipov wrote:
Oops, seems like somebody already solved this problem some days ago (and it's a pity that squishdot will not work on CVS version)
There are a number of reasons why I don't think this is that much of a pity. 1) Squishdot is based on very old, pre 2.0 code. It does all it's own indexing instead of using ZCatalog (because it is based on old code). It should not do that, and if it does, it should track the same indexing code as the catalog. As is, Squishdot cannot take advantage of the new language independent features, or wildcard searching, or Japanese support etc... 2) It's a *trivial* fix to Squishdot, but a huge waste of my time to maintain and document two different, incompatable interfaces just for Squishdot. 3) There are a number of products which do not have this limitation which work like Squishdot, such as KM|News and the upcoming PTK. There are other techical reasons, such as the old indexing code being very ZTables centric. I made the same mistake the original index authors made in that I made the Catalog indexes very ZCatalog centric. Neither are very useful in the general case (which is the real root of the problem here). -Michel
1) Squishdot is based on very old, pre 2.0 code. It does all it's own indexing instead of using ZCatalog (because it is based on old code). It should not do that, and if it does, it should track the same indexing code as the catalog. As is, Squishdot cannot take advantage of the new language independent features, or wildcard searching, or Japanese support etc...
I'm looking to pick up on Squishdot development until Butch Landigan has some free time, where can I find out how things 'should' be indexed? In general where should I look for documentation on the python-end of Zope development?
There are other techical reasons, such as the old indexing code being very ZTables centric. I made the same mistake the original index authors made in that I made the Catalog indexes very ZCatalog centric. Neither are very useful in the general case (which is the real root of the problem here).
I think I'm missing something 'cos I dont' understand this :S Are you saying Catalog indexes are bad or are you saying ZCatalogs are badly designed? Chris
Chris Withers wrote:
1) Squishdot is based on very old, pre 2.0 code. It does all it's own indexing instead of using ZCatalog (because it is based on old code). It should not do that, and if it does, it should track the same indexing code as the catalog. As is, Squishdot cannot take advantage of the new language independent features, or wildcard searching, or Japanese support etc...
I'm looking to pick up on Squishdot development until Butch Landigan has some free time, where can I find out how things 'should' be indexed? In general where should I look for documentation on the python-end of Zope development?
The Interfaces Wiki: http://www.zope.org/Members/michel/Projects/Interfaces
There are other techical reasons, such as the old indexing code being very ZTables centric. I made the same mistake the original index authors made in that I made the Catalog indexes very ZCatalog centric. Neither are very useful in the general case (which is the real root of the problem here).
I think I'm missing something 'cos I dont' understand this :S Are you saying Catalog indexes are bad or are you saying ZCatalogs are badly designed?
They are not bad nor are they badly designed. They were designed before we starting taking a more seriously disciplined process toward development, and it was also my first serious Zope product. If I could do it over, I would do some minor re-engineering that would have eliminated these indexing problems, like basing the new indexes on the old indexes (subclassing). The problem was, the old indexes were too ZTables centric, and we could not 'fix' them because this would break ZTables/Confera, so a compromise was taken to have two different interfaces. So because the old interfaces did not do what ZCatalog wanted to do I created new ones that did, and thus, they were more ZCatalog centric. -Michel
participants (3)
-
Chris Withers -
Michel Pelletier -
Vitaly Osipov