I made several changes yesterday to ZCatalog that may be of interest to you if you have a product that subclasses or embeds ZCatalogs/Catalogs. For eternity, ZCatalog has, when instantiated, created a set of predefined indexes and metadata. Back in the day when we had only three index types, this made some sense. Also, some of the indexes were less than useful. For instance, bobobase_modification_time is really too low level to be used for what the Catalog suggests we use it for. Summary only exists in CatalogAware objects, etc. etc. Now that we have plug-in indexes, it makes even less sense to guess what people are going to use their catalogs for. The current code in the trunk no longer populates the ZCatalog with a predefined set of indexes or metadata. It is up to the user or application to do this now. Realizing that some products may rely on this behavior, I am sending this warning so that you have an opportunity to test it for yourself. Another anachronism in the Catalog was that it automatically created and maintained a reference to a Vocabulary/Lexicon object to be used by the TextIndexes. Now that we have 3 different kinds of TextIndex available, one of which (ZCTextIndex) does not even use the same type of lexicon objects, this makes no sense anymore. Besides the fact that TextIndex already can manage its vocabulary association by itself anyhow. So, I have removed the dependency of Catalog on Vocabulary. Catalogs no longer store a reference to or care about vocabularies. Also, vocabulary objects are not created or chosen when instantiating a new ZCatalog. Like with indexes, this is now up to the user or application code. -Casey
Casey Duncan wrote:
For eternity, ZCatalog has, when instantiated, created a set of predefined indexes and metadata. Back in the day when we had only three index types, this made some sense. Also, some of the indexes were less than useful. For instance, bobobase_modification_time is really too low level to be used for what the Catalog suggests we use it for. Summary only exists in CatalogAware objects, etc. etc. Now that we have plug-in indexes, it makes even less sense to guess what people are going to use their catalogs for.
Excellent. A lot of catalog-driven sites have trouble keeping the size of Data.fs down, and often the source of the problem is the catalog indexes and metadata fields left in place but never used.
The current code in the trunk no longer populates the ZCatalog with a predefined set of indexes or metadata. It is up to the user or application to do this now. Realizing that some products may rely on this behavior, I am sending this warning so that you have an opportunity to test it for yourself.
Currently, CMF falls under this category. :-(
Another anachronism in the Catalog was that it automatically created and maintained a reference to a Vocabulary/Lexicon object to be used by the TextIndexes. Now that we have 3 different kinds of TextIndex available, one of which (ZCTextIndex) does not even use the same type of lexicon objects, this makes no sense anymore. Besides the fact that TextIndex already can manage its vocabulary association by itself anyhow.
So, I have removed the dependency of Catalog on Vocabulary. Catalogs no longer store a reference to or care about vocabularies. Also, vocabulary objects are not created or chosen when instantiating a new ZCatalog. Like with indexes, this is now up to the user or application code.
I was happy when you told me this yesterday, but now that I've thought about it, I'm ecstatic. ;-) I once tried to dezopeify ZCatalog, and the vocabulary stuff was a major hurdle. (The next hurdle is acquisition, should we pursue this avenue further.) Shane
On Wed, 2002-06-12 at 13:32, Shane Hathaway wrote: [snip]
The current code in the trunk no longer populates the ZCatalog with a predefined set of indexes or metadata. It is up to the user or application to do this now. Realizing that some products may rely on this behavior, I am sending this warning so that you have an opportunity to test it for yourself.
Currently, CMF falls under this category. :-(
Yes, I have begun to fix it. I want to determine exactly which Indexes/metdata are really needed in CMF. Like, do we really need both Title and title indexes and metadata? How about bobobase_mod_time? I plan to fix it when I find the answers. -Casey
Casey Duncan writes:
Currently, CMF falls under this category. :-(
Yes, I have begun to fix it. I want to determine exactly which Indexes/metdata are really needed in CMF. Like, do we really need both Title and title indexes and metadata? How about bobobase_mod_time? I would twice answer with "no", we do not need.
Dieter
Hmm... which of 'title' and 'Title' is now considered correct form? That one certainly needs and index and metadata. The others probably not. Adrian... -- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk DISCLAIMER: Microsoft, Windows, Windows XP, Bugs, Lacking features, IRQ conflicts, System crashes, Non-functional multitasking, registration keys, the Y2K problem, the Blue Screen of Death and unfair business practices are registered trademarks of Microsoft Corp., Redmond, USA. ----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Casey Duncan" <casey@zope.com> Cc: "Shane Hathaway" <shane@zope.com>; <zope-dev@zope.org> Sent: Thursday, June 13, 2002 7:58 PM Subject: Re: [Zope-dev] Changes to ZCatalog
Casey Duncan writes:
Currently, CMF falls under this category. :-(
Yes, I have begun to fix it. I want to determine exactly which Indexes/metdata are really needed in CMF. Like, do we really need both Title and title indexes and metadata? How about bobobase_mod_time? I would twice answer with "no", we do not need.
Dieter
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Casey Duncan <casey@zope.com> wrote:
Yes, I have begun to fix it. I want to determine exactly which Indexes/metdata are really needed in CMF. Like, do we really need both Title and title indexes and metadata? How about bobobase_mod_time?
I plan to fix it when I find the answers.
I found (probably missed some, I haven't looked in detail at all dtml skins): Indexes: - AllowedRolesAndUsers, expires, effective (CatalogTool) - in_reply_to (DiscussionTool) - review_state (DefaultWorkflow, misc. scripts) - meta_type (misc. scripts) - Type (news_box.dtml) Probably a fossil, the ZPT version and other scripts use meta_type. A dedicated portal_type index would be even better. - Subject, created (search_form.pt, doFormSearch.py) - SearchableText, Title, Subject, Description, created, Type, Creator (search) Metadata: This is more difficult to grep for. I found: - Title, Date (news_box.pt) - title, Date, Creator, Description (recent_news.pt) Fossil, should use Title. - Title, icon, Type, Date, Description (review.pt) I think 'path' should be in the indexes by default too, even though I'm not sure CMF directly uses it now. The rest of Dublin Core should maybe be in the indexes and metadata. I think a portal_type index is needed. HTH, Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
(Cc to zope-cmf this time, please redirect discussions appropriately either to zope-dev or zope-cmf.) Also, icon (=getIcon, in CMFCore/DynamicType) is in the metadata, but it returns an absolute url. It would be better to have a getIconRelative metadata that does getIcon(relative_to_portal=1) so that it behaves ok in the presence of VHM. Florent Florent Guillaume <fg@nuxeo.com> wrote:
Casey Duncan <casey@zope.com> wrote:
Yes, I have begun to fix it. I want to determine exactly which Indexes/metdata are really needed in CMF. Like, do we really need both Title and title indexes and metadata? How about bobobase_mod_time?
I plan to fix it when I find the answers.
I found (probably missed some, I haven't looked in detail at all dtml skins):
Indexes:
- AllowedRolesAndUsers, expires, effective (CatalogTool)
- in_reply_to (DiscussionTool)
- review_state (DefaultWorkflow, misc. scripts)
- meta_type (misc. scripts)
- Type (news_box.dtml)
Probably a fossil, the ZPT version and other scripts use meta_type. A dedicated portal_type index would be even better.
- Subject, created (search_form.pt, doFormSearch.py)
- SearchableText, Title, Subject, Description, created, Type, Creator (search)
Metadata:
This is more difficult to grep for. I found:
- Title, Date (news_box.pt)
- title, Date, Creator, Description (recent_news.pt)
Fossil, should use Title.
- Title, icon, Type, Date, Description (review.pt)
I think 'path' should be in the indexes by default too, even though I'm not sure CMF directly uses it now.
The rest of Dublin Core should maybe be in the indexes and metadata.
I think a portal_type index is needed.
HTH, Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
Casey Duncan wrote:
I made several changes yesterday to ZCatalog that may be of interest to you if you have a product that subclasses or embeds ZCatalogs/Catalogs.
<snip>
Hmm ... I have subscribed to zope-dev for the longest time now, and as far as I remember this is the first time I have seen a simple and concise explanation of a change taking place. I wonder where this information usually is dissiminated. I would imagine that zope-dev should be filled with information like this, but it very rarely is. Is information about Zope development only discussed orally at zope.com, or is attached as comments in the cvs, or where do you guys keep each other up to date about changes taking place? regards Max M -- "Sorry I would Really Like To Help More On This Project, But Am To Busy Doing Paid Work On A Tight Deadline" Max M
Max M wrote:
Is information about Zope development only discussed orally at zope.com, or is attached as comments in the cvs, or where do you guys keep each other up to date about changes taking place?
There are dozens (sometimes hundreds) of updates, usually posted with nearly complete documentation and updates to unit tests, every day. To keep in the loop, just read. ;-) http://lists.zope.org/pipermail/zope-checkins/ http://dev.zope.org/Wikis/DevSite/Proposals/FrontPage http://dev.zope.org/Projects/ http://lists.zope.org/pipermail/zope3-dev/ Shane
On Thu, 2002-06-13 at 02:43, Max M wrote:
Casey Duncan wrote:
I made several changes yesterday to ZCatalog that may be of interest to you if you have a product that subclasses or embeds ZCatalogs/Catalogs.
<snip>
Hmm ... I have subscribed to zope-dev for the longest time now, and as far as I remember this is the first time I have seen a simple and concise explanation of a change taking place.
Thanks, I will try to do more of these messages as I make/see changes like this in the trunk.
I wonder where this information usually is dissiminated. I would imagine that zope-dev should be filled with information like this, but it very rarely is.
I think it should be. I think very few people read the checkin messages, and they seldom contain "big picture" narrative anyhow. I think messages here should be sent when there are big picture impacts. It can act like informal historical documentation.
Is information about Zope development only discussed orally at zope.com, or is attached as comments in the cvs, or where do you guys keep each other up to date about changes taking place?
We have weekly "jam sessions" where we often hash out new ideas. Certainly the CVS is commented, but it is at quite a low level. I think we (ZC'ers) all know we can do a better job desseminating our ideas to the community. It really a question of bandwidth (or lack thereof). On the bright side, your message has inspired me to be a bit more of a "narrator". It's always glad to hear when people actually read something I write and get something out of it.
regards Max M
--
"Sorry I would Really Like To Help More On This Project, But Am To Busy Doing Paid Work On A Tight Deadline" Max M
Ain't it the truth ;^) -Casey
On Thursday 13 Jun 2002 3:02 pm, Casey Duncan wrote:
I wonder where this information usually is dissiminated. I would imagine that zope-dev should be filled with information like this, but it very rarely is.
I think it should be. I think very few people read the checkin messages, and they seldom contain "big picture" narrative anyhow.
A while ago I had my email client set up with a filter that hid most of the checkins list, except commits to doc/CHANGES.txt. That works reasonably well. Today, I read all the checkins list. What a joy.
On 13 Jun 2002, Casey Duncan wrote:
We have weekly "jam sessions" where we often hash out new ideas. Certainly the CVS is commented, but it is at quite a low level. I think we (ZC'ers) all know we can do a better job desseminating our ideas to the community. It really a question of bandwidth (or lack thereof).
An audio stream wouldn't take much bandwidth :) :) --RDM
participants (8)
-
Adrian Hungate -
Casey Duncan -
Dieter Maurer -
Florent Guillaume -
Max M -
R. David Murray -
Shane Hathaway -
Toby Dickenson